ramzswap: Eliminate stale data from compressed memory (v2)
in [Kernel]
|
Prev: [PATCH 2/3] Add swap slot free callback to block_device_operations
Next: [git pull] more PCMCIA bugfixes for 2.6.34-rc6
From: Nitin Gupta on 8 May 2010 03:10 Oops, missed this part: On 05/08/2010 11:59 AM, Pekka Enberg wrote: > Andrew Morton wrote: >> I've completely forgotten why we need this xvmalloc thing and I don't >> recall whether we decided it would be a good thing to have as a generic >> facility and of course it's all unexplained and undocumented. I won't >> be looking at it today, for this reason. > > We need it because the slab allocator is not a good fit for this special > purpose driver due to fragmentation. Nitin, you had a nice web page > showing all the relevant numbers but I can't find it anymore. > xvmalloc performance numbers: http://code.google.com/p/compcache/wiki/xvMalloc http://code.google.com/p/compcache/wiki/xvMallocPerformance Thanks, Nitin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 8 May 2010 03:10 Nitin Gupta wrote: > Its not debug code. This ioctl is how we send stats about given ramzswap > device to userspace: rzscontrol /dev/ramzswap --stats, invokes this ioctl > and prints the stats. I will add comments to this part to make it clear. Another option would be sysfs if you want the stats to always be available. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 8 May 2010 03:30 Nitin Gupta wrote: > Oops, missed this part: > > On 05/08/2010 11:59 AM, Pekka Enberg wrote: >> Andrew Morton wrote: >>> I've completely forgotten why we need this xvmalloc thing and I don't >>> recall whether we decided it would be a good thing to have as a generic >>> facility and of course it's all unexplained and undocumented. I won't >>> be looking at it today, for this reason. >> We need it because the slab allocator is not a good fit for this special >> purpose driver due to fragmentation. Nitin, you had a nice web page >> showing all the relevant numbers but I can't find it anymore. >> > > xvmalloc performance numbers: > http://code.google.com/p/compcache/wiki/xvMalloc > http://code.google.com/p/compcache/wiki/xvMallocPerformance I don't see the xvmalloc vs. kmalloc fragmentation numbers there. I thought you had some? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nitin Gupta on 8 May 2010 03:40
On 05/08/2010 12:56 PM, Pekka Enberg wrote: > Nitin Gupta wrote: >> Oops, missed this part: >> >> On 05/08/2010 11:59 AM, Pekka Enberg wrote: >>> Andrew Morton wrote: >>>> I've completely forgotten why we need this xvmalloc thing and I don't >>>> recall whether we decided it would be a good thing to have as a generic >>>> facility and of course it's all unexplained and undocumented. I won't >>>> be looking at it today, for this reason. >>> We need it because the slab allocator is not a good fit for this special >>> purpose driver due to fragmentation. Nitin, you had a nice web page >>> showing all the relevant numbers but I can't find it anymore. >>> >> >> xvmalloc performance numbers: >> http://code.google.com/p/compcache/wiki/xvMalloc >> http://code.google.com/p/compcache/wiki/xvMallocPerformance > > I don't see the xvmalloc vs. kmalloc fragmentation numbers there. I > thought you had some? > TLSF vs kmalloc (SLUB): http://code.google.com/p/compcache/wiki/AllocatorsComparison By design, xvmalloc is very similar to TLSF. In fact, xvmalloc has less metadata overhead than TLSF. So, we will surely get similar results for xvmalloc vs kmalloc comparison too. Thanks, Nitin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |