Messages in this thread |  | | | Date | Wed, 18 Mar 2009 21:37:35 +0530 | | From | Nitin Gupta <> | | Subject | Re: [PATCH 2/3]: xvmalloc memory allocator |
| |
Pekka Enberg wrote: > On Tue, 17 Mar 2009, Nitin Gupta wrote: >>> Creating slabs for sizes in range, say, [32, 3/4*PAGE_SIZE] separated by >>> 64bytes >>> will require 48 slabs! Then for slab of each size class will have wastage >>> due to >>> unused slab objects in each class. >>> Larger difference in slab sizes (and thus small no. of them), will surely >>> cause too much >>> wastage due to internal fragmentation. > > On Tue, Mar 17, 2009 at 10:58 AM, Christoph Lameter > <cl@linux-foundation.org> wrote: >> The slabs that match existing other slabs of similar sizes will be aliased >> and not created. Create the 48 slabs and you likely will only use 10 real >> additional ones. The rest will just be pointing to existing ones. > > Yup. One thing I don't quite understand is why you need all the 48 > caches in the first place. Allocation sizes tend to be clustered and I > would have imagined you'd see that when compressing page sized chunks > as well.
Compressed page lengths sometimes do tend to cluster within somewhat small range. However, the range of where majority of pages will lie depends highly of workload - sometimes range is not clear and sometime there is no preferred range at all. Please refer this data: http://code.google.com/p/compcache/wiki/CompressedLengthDistribution
It shows compressed page size distribution for various workloads.
> Using kmemtrace to analyze the exact reason for the bad > fragmentation would probably be helpful. >
That was purely internal fragmentation. Wastage per obj = ksize(obj) - actual_size.
Code used for testing: http://code.google.com/p/compcache/source/browse/trunk/sub-projects/testing/kmalloc_test/kmalloc_test.c This is a "SwapReplay client". Please see: http://code.google.com/p/compcache/wiki/SwapReplayDesign
Thanks, Nitin
|  |