3 ms·
mold seems very cool! The design notes [1] are fabulous, exactly the kind of documentation I look for for stuff like this. This part, in particular, is genius:
by OskarS 4y ago
mold seems very cool! The design notes [1] are fabulous, exactly the kind of documentation I look for for stuff like this. This part, in particular, is genius:
> As we aim to the 1-second goal for Chromium, every millisecond counts. We can't ignore the latency of process exit. If we mmap a lot of files, _exit(2) is not instantaneous but takes a few hundred milliseconds because the kernel has to clean up a lot of resources. As a workaround, we should organize the linker command as two processes; the first process forks the second process, and the second process does the actual work. As soon as the second process writes a result file to a filesystem, it notifies the first process, and the first process exits. The second process can take time to exit, because it is not an interactive process.
Never heard about this trick before, but it's the rare combination of "genius" and "obvious in retrospect".
[1]: https://github.com/rui314/mold/blob/main/docs/design.md https://github.com/rui314/mold/blob/main/docs/design.md
- klysm 4y agoI wonder why the cleaning up of those mmaps is synchronous
- mcculley 4y agoI would imagine it is just because it would require more complexity in the kernel. One would need to create a queue of tasks to be performed during cleanup and have the path through the exit system call know to push work onto that queue. It sounds like there is an opportunity for someone to submit a diff to the Linux kernel for improving exit userspace latency.