On Tue, Mar 06, 2018 at 12:34:05PM -0600, Christopher Lameter wrote:
> On Mon, 5 Mar 2018, Alexey Dobriyan wrote:
>
> > struct kmem_cache::size has always been "int", all those
> > "size_t size" are fake.
>
> They are useful since you typically pass sizeof( < whatever > ) as a
> parameter to kmem_cache_create(). Passing those values onto other
> functions internal to slab could use int.
Sure, but:
struct foo {
int n;
char *p;
};
int f(unsigned int x);
int g(void)
{
return f(sizeof(struct foo));
}
gives:
0: bf 10 00 00 00 mov $0x10,%edi
5: e9 00 00 00 00 jmpq a <g+0xa>
Changing the prototype to "int f(unsigned long x)" produces _exactly the
same assembly_. Why? Because mov to %edi will zero out the upper 32-bits
of %rdi. I consider it one of the flaws in the x86 instruction set that
mov %di doesn't zero out the upper 16 bits of %edi (and correspondingly
the upper 48 bits of %rdi), as it'd save an awful lot of bytes in the
instruction stream by replacing 32-bit constants with 16-bit constants.
There's just no difference between these two. Unless you want to talk
about a structure exceeding 4GB in size, and then I'm afraid we have
bigger problems.
--
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>
