Messages in this thread | | | Date | Tue, 22 Nov 2011 18:53:21 -0800 (PST) | From | David Rientjes <> | Subject | Re: Slub Allocator: Why get_order(size * MAX_OBJS_PER_PAGE) - 1 in function slab_order()? |
| |
On Wed, 23 Nov 2011, zhihua che wrote:
> Hi, everyone, > I'm reading the kernel codes about slub allocator and I come > across a confusion. Precisely, I'm reading the initialization of the > slub allocator, kmem_cache_init(), and I find it needs call > calculate_sizes() to determine the order of a kmem_cache, given the > size of the object. In turn, it calls the get_order() to get a > possible order. The problem is, in the start of this function, why it > looks like this: > > if (order_objects(min_order, size, reserved) > MAX_OBJS_PER_PAGE) > return get_order(size * MAX_OBJS_PER_PAGE) - 1; > > I don't know why it subtracts one from the order returned by > get_order(). > because as far as I know, get_order() returns the order the > slab requires to reserve size * MAX_OBJS_PER_PAGE memory. If it > subtracts 1 from the order returned by get_order(), the slab can't > store MAX_OBJS_PER_PAGE objects at all, instead it can only store half > of the MAX_OBJS_PER_PAGE objects. > Could you correct me if I think in a wrong way.
I agree it looks confusing, but it's correct. SLUB can only store MAX_OBJS_PER_PAGE because of limitations in struct page (see the comments in include/linux/mm_types.h). So if the order will yield a page that could fit _more_ than MAX_OBJS_PER_PAGE, we need to reduce the order by a factor of 1.
| |