OSDev.org

Hi, OSDev, haven't been posting here for a while!

You might have heard about batch system calls that, however, have the drawback of requiring application support. What if instead of directly dispatching the issued system calls to the kernel the standard library would add them to a queue (without calling the kernel) which upon certain conditions (expiration of a time slice?) would be reaped by the kernel? This way the overhead of system calls could be shrank — such would be especially beneficial given the recent events (publication of Meltdown and Spectre whose mitigations require costlier system calls). I wonder if this technique is a good idea for either a POSIX system or a novel OS design.

The problem is you can't batch them if application want results immediately. To enable batched system call, the calls themselves needed to be designed with async nature in mind.

PS. interrupts on the other hand, can be batched that way (e.g. certain NIC support that) to reduce context switching.

@bluemoon: I see your point, but if hybrid threading was used then the standard library could simply switch to a different thread with no system call overhead. If no non-blocked threads were found then it would call the kernel to process the queue prematurely.

I think that this can work if it is combined with explicit (and not implicit) flushes. One problem with implicit flushing is that you actually want system calls to issue I/O requests as fast as possible to avoid introducing additional latency. However, the greatest problem here is that existing APIs like POSIX and the C and C++ standard libraries expect most calls (e.g. memory allocation, thread creation, thread synchronization, IPC and I/O) to be blocking and that does not work with explicit flushing: It forces you to flush for single system calls and thus does not improve performance.

Roman wrote:@bluemoon: I see your point, but if hybrid threading was used then the standard library could simply switch to a different thread with no system call overhead. If no non-blocked threads were found then it would call the kernel to process the queue prematurely.

This would make batch possible, but create a side effect that might not be desired: calling kernel means yielding a thread, if the scheduler itself is sophisticated it may create unpredictable results.

You might be interested in reading the FlexSC paper, where they implement a similar method.

https://www.usenix.net/legacy/events/os ... Soares.pdf

lkurusa wrote:You might be interested in reading the FlexSC paper, where they implement a similar method.

https://www.usenix.net/legacy/events/os ... Soares.pdf

Thanks for the link, I'll definitely check it out.