use huge pages for code and read-only data [LWN.net]

use huge pages for code and read-only data

Posted Mar 29, 2017 12:09 UTC (Wed) by sorokin (guest, #88478)
Parent article: Supporting shared TLB contexts

> Arcangeli went on to say that the real problem with TLB performance is that Linux is still using small (4KB) pages; someday that page size is going to have to increase.

Probably a bit of offtopic, I want to ask nonetheless.

Some time ago I thought about how can OSes use huge pages and global pages widely. My idea was to load all text sections and all read-only data sections into huge pages available to all processes at the same addresses.

Pros are:
+ These pages can be huge (reducing TLB overhead)
+ These pages can be made global (reducing TLB overhead during process switching)
− The first loading of a shared-object will be slow (we can not do lazy binding, because the shared area can not be made writeble by userspace processes)
+ The second and next loadings of a shared-object will be instantaneous
+ No GOT and PLT overhead (fast shared libraries)
− Kernel needs to somehow arbitrate the process of loading and unloading shared-objects (implementation complexity), most likely kernel needs to be aware what shared libraries are loaded into which processes
− ASLR doesn't work
− Makes ROP easier (lots of code are loaded into each process)
± Probably practical only on 64-bit systems where we have plenty of available virtual space

So for me it sounds like we have better performance at expense of reduced exploit mitigation. What do others think? Do you think these trade-offs are reasonable? Or are my ideas completely crazy?

to post comments

use huge pages for code and read-only data

Posted Mar 29, 2017 17:37 UTC (Wed) by hansendc (subscriber, #7363) [Link]

Could we do this? Sure. AIX did something like it.

Is it worth it? Probably not. For instance, we can't currently use large pages to map text (without app recompiling or using an LD_PRELOAD). We also can't cross a VMA boundary with a single huge page. Each shared library currently requires its own VMA (or set of them). Some of the library is mapped read-only, and some of it is read-write and MAP_PRIVATE. A huge page must be either r/w *or* r/o.

You bring up a bunch of ways that things *could* be faster, but they are not currently large pain points for most applications.