Why is kmem_bufctl_t different across platforms?

[Kyle Moffett <mrmacman_g4@mac.com>]

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