Lightweight Guard Pages For Linux Showing 5x Speed-Up For Memory Mapping Invocations

[phoronix]

Phoronix: Lightweight Guard Pages For Linux Showing 5x Speed-Up For Memory Mapping Invocations

Patches posted this week by Oracle's Lorenzo Stoakes are the latest attempt at lightweight guard pages for the Linux kernel...

https://www.phoronix.com/news/Linux-Lightweight-Guard-Pages

[TheDcoder]

Wow, this looks like a major performance improving patch! Hope it lands soon

[Hi-Angel]

Seems to be pretty useful. I see lots of `mmap`s being called with `PROT_NONE` every second on my laptop:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_mmap{ if (! args->prot) {printf("mmap called by PID %d (%s): addr=%x, prot=%x\n", pid, comm, args->addr, args->prot);} }'
​

[curfew]

Seems to be pretty useful. I see lots of `mmap`s being called with `PROT_NONE` every second on my laptop:

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_mmap{ if (! args->prot) {printf("mmap called by PID %d (%s): addr=%x, prot=%x\n", pid, comm, args->addr, args->prot);} }'
​

If you are able to print all the calls into a terminal without choking your whole machine, then this optimization will not have any slightest effect in your life ever.

Yes, it's that's small.

[Hi-Angel]

If you are able to print all the calls into a terminal without choking your whole machine, then this optimization will not have any slightest effect in your life ever.

Yes, it's that's small.

I guess you are right. OTOH, I was rather curious in terms "is it useful on desktop"? Because, for example, Glibc rseq AFAIK is still only used for `getcpu`, and `getcpu` performance AFAIK isn't interesting to an average user. This `mmap` with `PROT_NONE` OTOH I see being used in desktop apps, so imagine there might be some CPU-intensive workflow where that might help a tiny bit.

[Developer12]

If you are able to print all the calls into a terminal without choking your whole machine, then this optimization will not have any slightest effect in your life ever.

Yes, it's that's small.

That's for the *creation* of these areas. The problematic overhead occurs at runtime, as areas that have already been created are set up and torn constantly during context switches, as well as the accumulated memory taken up by the required bookkeeping.