The Linux kernel can spawn processes on its own
uninformativ.de
uninformativ.de
There are some mechanisms that can call back into userspace during syscalls such as seccomp filters, FUSE, ptrace, userfaultfd, fanotify, the syscall_user_dispatch feature used by wine... There's the core_pattern handler too.
Someone summarized it that a mov instruction could be serviced by starting a python process.
sleep(3) the kernel blocks for a time specified by userspace. futex(2) can cause the kernel to block until usespace wakes it. Similar wait(2). Also read(2) from a pipe or localhost socket.
So whether or not it is a bad design depends highly on what gets blocked, in what situations, and what can be done to recover the situation if things misbehave.
[1]: https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-...
For example, `man 2 select` (or `man select.2`) gives you information about the `select` syscall, and `man 3 select` has information on the libc wrapper around that syscall.
A somewhat better example might be time: `time.1` has info on the command use to calculate running time of another command (in statements like `time make -j`, and `time.7` — low-level information on how to interact with kernel's time-related functionality. Since both are named `time`, if you just use `man time` without the number, you get the first one (and no way to get to the second).
Read `man man`, it has a lot more on this stuff.
The table below shows the section numbers of the manual followed by the types of pages they contain.
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions, e.g. /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7), man-pages(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]In NT, KeUserModeCallback implements some sort of a coroutine pattern, where the kernel space can call back to the user code synchronously in the same thread and expect it to return to the callsite. In Linux, there's no such thing as a user-mode callback: a given thread cannot have any user code running (or scheduled to be run) while simultaneously having the kernel call stack active.
> seccomp filters, FUSE, ptrace, userfaultfd, fanotify
> core_pattern handler
> usermode helpers
These either block the current thread waiting for another thread (e.g. a debugger, fault handler, or filesystem server) to complete the request, or fires off the request asynchronously.
> syscall_user_dispatch
This does not "call back" into userspace at all; it merely delivers SIGSYS. Signal delivery works more like NT's user APCs: there's no kernel-side context active in the thread the signal handler (or the APC) is running.
But NT's hidden VMS-esque API for upcalls would be somewhat nicer option at times (or Solaris Doors)
What? You did not ask for a method that is not completely batshit insane.
https://www.quora.com/What-is-kswapd0-in-Linux-Kernel
https://stackoverflow.com/questions/9154042/where-can-i-find...
Here's some official documentation on it:
https://tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO-8.h...
And then there's this: https://www.bleepingcomputer.com/news/security/bpfdoor-steal...
A lot of (local) filesystems seem to do this as well (XFS in particular).
Try this command:
ps axo pid,ppid,comm | less
Perhaps one can do this or almost do this with io_uring?
Why is the OS scheduler alone in a better position than make itself to make the right call?
An elegant design on doing this in userspace probably boils down to going well on the awy to making a micro kernel.
I don't know if this is best handled by the OS, userspace Ninja, or some combination (like cgroups).
Think about the case where you have 32 CPUs, and so make starts 32 of the first tasks in the dependency graph. 31 of those tasks are routine compilations, but 1 task computes some data that a ton of other compilations need. What make and the OS don't know is that task would be 32x faster if was using all 32 CPUs. So by starting 31 random compilations, it's actually increasing the end-to-end latency dramatically, because so many things depend on that 1 job running as quickly as possible.
make and the OS basically only solve one tiny part of the problem of fast builds; maximize cpu utilization right now. They don't have enough data to make the latency of the build faster. It's very much a "good enough" approach; lots of people have faster builds because of "make -j32", but it could hardly be considered general enough to guarantee the fastest possible end-to-end build time. (And even things like Bazel don't quite have enough information to do this. Imagine you have some test that does "sleep 60" in the middle; you really want parallelism to go up to 33 when the test enters that state, and you want to ensure that you start it 60 seconds before the rest of the tests will be finished. There isn't enough data in the BUILD file to do that, though, so you're just stuck.)
Anyway, one thing you can do is get more memory and set -j higher than the number of cores/vCPUs. I think the kernel does a good job ensuring that each job makes progress, so if you have a scenario where something like a test benefits from starting as early as possible in the build and then basically goes to sleep, you'll still use 100% of your CPU, but make progress on that wait. The downside is that these things use a lot of RAM. I remember trying to build Envoy on a 64 vCPU machine once; each C++ process used over a gig of RAM, and I simply didn't have enough. I got more, and found that running 64 parallel compiles with SMT was about 10% faster than 32 parallel compiles. But, requires double the RAM (think it was about 80GB).
TL;DR lots of constraints to balance and optimize. Make is probably going to be the worst performing build system that you can use, but the field is hardly a "solved problem", and further research could probably yield general improvements. Also, buy yourself a lot of RAM when it's cheap. Having some code paged in and ready to go when the CPU is free is good for throughput.
make, of course, doesn’t know what gcc is either but at least it has a better chance of learning.
(The OS does know what resources current processes are using, but that doesn’t help because it doesn’t know what any future process will do. Designs like GCD solve this with priority levels, but that doesn’t help because all your make tasks are the same high priority.)