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
Cheers,
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |