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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
