User: Password:
|
|
Subscribe / Log in / New account

Supporting variable-sized huge pages

Supporting variable-sized huge pages

Posted Jan 24, 2013 7:47 UTC (Thu) by pr1268 (subscriber, #24648)
Parent article: Supporting variable-sized huge pages

The day when the mmap() flags bit space is exhausted seems to be slowly but steadily approaching. When that happens...

Why not change the flags type from int to a new aliased data type, e.g. flagset_t1 (itself typedef'ed to int currently, and then later, when needed, re-typedefed to int64_t)?

Yes, I realize this is easier said than done, and it would require changes to both userspace and the kernel, but if the change were made now then it would get glibc and friends time to work out issues associated with the API change. If this is too radical or ugly change to make, then I'll certainly plead guilty to being naïve.

In both system calls, the huge page size is encoded in the six bits from 26 through to 31

I, for one, think Andi's method of storing numeric values in the high-order bits of flags is quite elegant2.

1 My motivation for suggesting "flagset_t" was based on seeing all the *_t types contained within a struct stat (see stat(2) ).

2 I've used a similar technique in storing both options flags and numeric values in a single 32-bit integer when using getopt(3).


(Log in to post comments)

Supporting variable-sized huge pages

Posted Jan 25, 2013 18:20 UTC (Fri) by justincormack (subscriber, #70439) [Link]

That works on 64 bit architectures but will cause issues on 32 bit as you would need a new system call as the ABI is changed by extending flags...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds