On Fri, Sep 06, 2013 at 03:58:18PM +0000, Christoph Lameter wrote: > On Fri, 6 Sep 2013, Joonsoo Kim wrote: > > > Currently, the freelist of a slab consist of unsigned int sized indexes. > > Most of slabs have less number of objects than 256, since restriction > > for page order is at most 1 in default configuration. For example, > > consider a slab consisting of 32 byte sized objects on two continous > > pages. In this case, 256 objects is possible and these number fit to byte > > sized indexes. 256 objects is maximum possible value in default > > configuration, since 32 byte is minimum object size in the SLAB. > > (8192 / 32 = 256). Therefore, if we use byte sized index, we can save > > 3 bytes for each object. > > Ok then why is the patch making slab do either byte sized or int sized > indexes? Seems that you could do a clean cutover? > > > As you said: The mininum object size is 32 bytes for slab. 32 * 256 = > 8k. So we are fine unless the page size is > 8k. This is true for IA64 and > powerpc only I believe. The page size can be determined at compile time > and depending on that page size you could then choose a different size for > the indexes. Or the alternative is to increase the minimum slab object size. > A 16k page size would require a 64 byte minimum allocation. But thats no > good I guess. byte sized or short int sized index support would be enough. Sorry for misleading commit message. 32 byte is not minimum object size, minimum *kmalloc* object size in default configuration. There are some slabs that their object size is less than 32 byte. If we have a 8 byte sized kmem_cache, it has 512 objects in 4K page. Moreover, we can configure slab_max_order in boot time so that we can't know how many object are in a certain slab in compile time. Therefore we can't decide the size of the index in compile time. I think that byte and short int sized index support would be enough, but it should be determined at runtime. > > > This introduce one likely branch to functions used for setting/getting > > objects to/from the freelist, but we may get more benefits from > > this change. > > Lets not do that. IMHO, this is as best as we can. Do you have any better idea? Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>