Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's simply that doing that many system calls takes that amount of time. Even though everything is hot in the cache, make still needs to call stat on every single file in the kernel source tree, to detect those files that have changed.

The suggestion in the comments to allow a Windows-style batched stat is a good idea. This means that more work is done per system call, reducing the number of calls and therefore the amount of time spent saving the CPU state to switch to kernel mode, and then restoring it again to switch back.



The system calls are plenty fast. As I mentioned, we got Chrome's build of comparable size to around a second, and it still stats every file.

(A batched stat would be nice too, but it's not the most critical thing to optimize.)


Linus says it is about 5% of the time taken in his run. Well, 5% of 30 seconds is not too far off a second.

But yes, the kernel build is doing all sorts of stuff other than stat, like starting shells and sub instances of make.


Linus says about page fault overhead, not system call. I understand this is a much different thing. On x86 page fault raises an interrupt. For a system call there is an instruction designed for fast control transfer to avoid costly interrupt


> The system calls are plenty fast

No they are not. Cutting context switches in system calls is one of the easiest ways of boosting throughput in your average unoptimized Linux app, in my experience. Exactly because so many developers go around ignoring the cost of system calls.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: