[lkml]   [2005]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectWhy is kmem_bufctl_t different across platforms?
While exploring the asm-*/types.h files, I discovered that the
type "kmem_bufctl_t" is differently defined across each platform,
sometimes as a short, and sometimes as an int. The only file
where it's used is mm/slab.c, and as far as I can tell, that file
doesn't care at all, aside from preferring it to be a small-sized
type. I found this comment:

> /*
> * kmem_bufctl_t:
> *
> * Bufctl's are used for linking objs within a slab
> * linked offsets.
> *
> * This implementation relies on "struct page" for locating the
> cache &
> * slab an object belongs to.
> * This allows the bufctl structure to be small (one int), but limits
> * the number of objects a slab (not a cache) can contain when off-
> slab
> * bufctls are used. The limit is the size of the largest general
> cache
> * that does not use off-slab slabs.
> * For 32bit archs with 4 kB pages, is this 56.
> * This is not serious, as it is only for large objects, when it is
> unwise
> * to have too many per slab.
> * Note: This limit can be raised by introducing a general cache
> whose size
> * is less than 512 (PAGE_SIZE<<3), but greater than 256.
> */

It appears to state that the max kmem_bufctl_t value is ~56 on most
setups, although it could be higher with 64-bit or bigger pages.
Since this value is never used by anything except that kernel-internal
file, should it be unified across all architectures? If so, I'll send
a patch to remove the various typedefs and introduce a single
"typedef unsigned short kmem_bufctl_t" in include/linux/types.h

Kyle Moffett

Premature optimization is the root of all evil in programming
-- C.A.R. Hoare

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-28 23:44    [W:0.032 / U:5.596 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site