Not really userspace

Posted Jul 18, 2024 7:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Not really userspace by wahern
Parent article: Redox to implement POSIX signals in user space

> POSIX permits longjmp'ing from a signal handler and this can be used in a well-defined manner to greatly increase (as in 10-100x) the performance of certain operations, such as hardware-accelerated array boundary checking, for which you would usually use a synchronous signal like SIGSEGV.

"Press [X] to doubt".

Signals are not at all fast because they necessarily involve several context switches. I wrote a short benchmark: https://gist.github.com/Cyberax/5bd53bff3308d6e026d414f93... - it takes about 2 seconds on my Linux machine to run 1 million iterations of SIGSEGV handling.

Perf data: https://gist.github.com/Cyberax/aa96a237a9b04ed6f25e09c63... - so around 500k signals per second. That's not bad, but it's also not that _great_ for a good primitive for high-performance apps.

Not really userspace

Posted Jul 18, 2024 8:31 UTC (Thu) by mgb (guest, #3226) [Link] (1 responses)

But what if most of your array accesses are in bounds and don't cause a signal?

Not really userspace

Posted Jul 18, 2024 19:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Probably. But it can safely work only with hardware-assisted bounds control, where each pointer is annotated with a length.

And if you have such hardware capabilities, you should use a different primitive for flow control.

Not really userspace

Posted Jul 18, 2024 9:40 UTC (Thu) by 4lDO2 (guest, #172237) [Link] (2 responses)

A SIGSEGV signal, which on Redox will be handled as an 'exception' that userspace can later call a signal handler for (basically the same type of jump, passing the page fault address, old instr pointer, page fault flags, etc), does *not* necessarily require several context switches. In fact, it can in theory be just as fast as a kernel-corrected page fault, which should be slightly but not significantly slower than a syscall, i.e. two mode switches. It wouldn't surprise me if Linux's implementation is not as efficient though.

The point of catching SIGSEGV this way, is not that exceptions are faster than checks, but that they *are* faster overall if the probability of the check failing, is low enough to justify avoiding this check in the general case. After all, this is why Linux (and Redox) implements copy_from_user as a catchable memcpy function, rather than walking the page tables every time. Most applications won't EFAULT more than once.

Not really userspace

Posted Jul 18, 2024 19:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> A SIGSEGV signal, which on Redox will be handled as an 'exception' that userspace can later call a signal handler

FWIW, Windows also uses a similar model. Memory faults can be caught via SEH ("Structured Exception Handling"). It still has to round-trip through the kernel, but it's more lightweight compared to signals.

> The point of catching SIGSEGV this way, is not that exceptions are faster than checks, but that they *are* faster overall if the probability of the check failing, is low enough to justify avoiding this check in the general case. After all, this is why Linux (and Redox) implements copy_from_user as a catchable memcpy function, rather than walking the page tables every time. Most applications won't EFAULT more than once.

Sure, but then it's also fine if the signal handling is done through a userland process/thread. It will add a couple of context switches, but it'll still be fast enough.

Not really userspace

Posted Jul 19, 2024 16:16 UTC (Fri) by 4lDO2 (guest, #172237) [Link]

> FWIW, Windows also uses a similar model. Memory faults can be caught via SEH ("Structured Exception Handling"). It still has to round-trip through the kernel, but it's more lightweight compared to signals.

That's pretty cool. My understanding is that Windows generally offloads much more logic to userspace, as they can freely change the kernel/user ABI.

> Sure, but then it's also fine if the signal handling is done through a userland process/thread. It will add a couple of context switches, but it'll still be fast enough.

Yeah probably. Redox will most likely implement userspace exception handling synchronously, like signals, but for many workloads those edge cases would presumably not be that noticeable either way.

Not really userspace

Posted Jul 20, 2024 0:53 UTC (Sat) by am (subscriber, #69042) [Link]

I'm not sure about bounds checking, but it's true that the JVM uses SIGSEGV for optimizations. It's optimizing for cases where it doesn't happen, though.

If you have hot code with branches checking for null that aren't being taken, the JIT will simply optimize out the checks, giving you better throughput. If a value happens to be become null after all, it will dereference it, catch the SIGSEGV, throw out the optimized code ("deoptimize"), and then continue where it left off, giving you a little latency spike.