6 ms·

Linus wrote: 'Even a fully built kernel ("allmodconfig", so a pretty full build) takes about half a minute on my normal desktop to say "I'm done, that pull chan

by evmar 12y ago

Linus wrote: 'Even a fully built kernel ("allmodconfig", so a pretty full build) takes about half a minute on my normal desktop to say "I'm done, that pull changed nothing I could compile".' Since it's just after a git operation all the file state should be warm in the disk cache. It really shouldn't take that long. The Linux kernel (at least by looking at [1]) is about the same size in terms of file count as Chromium, and we got this operation down to about a second by using better tools (i.e. non-recursive make and then eventually a replacement). I appreciate that the kernel has its own requirements (it sounds like his no-op builds are still running shell scripts, something you ought to avoid in your critical path) and also it's great that he's running it this way in part to help profile a "normal" workload... but I'm also a bit sad to see so much time spent waiting for something slower than necessary, as well as time spent optimizing what feels like the wrong thing. [1]: http://larjona.wordpress.com/2011/06/15/numbers-about-the-linux-kernel-2-6-38-2/ http://larjona.wordpress.com/2011/06/15/numbers-about-the-li...

josephg 12y ago
From further down in the comment thread, Linus says that speeding this up should help other workloads too, and he's sick of using make replacements: --- +Peter oh, it's absolutely true that 'make' is a pig, and does too much, and we don't exactly help the situation by using tons of GNU make features and complex variables and various random shell escapes etc etc. So there's no question that some "makefile compiler" could optimize this all. But quite frankly, I've had my fill of random make replacements. imake, cmake, qmake, they all solve some problem, and they all have their own quirks and idiocies. So while I'd love for 'make' to be super-efficient, at the same time I'd much rather optimize the kernel to do what make needs really well, and have CPU's that don't take too long either. Because let's face it, even if the kernel build process was some super-efficient thing, real life isn't that anyway. I guarantee you that the "tons of small scripts etc" that the kernel build does is a real load somewhere totally unrelated. Optimizing page faults will help other loads.
- danudey 12y ago
  Maybe he'll get so fed up with make that he'll write his own that everyone can just switch to instead of all the crud we have.
  - tedks 12y ago
    Oh no. Not on your life. It would be better for the entire world if Linus had a heart attack rather than rewriting Make. Make is already unusable; git-style make would be an abomination. Can you even imagine reading the man pages of all the different git-make commands? The syntax? I hope Linus keeps contributing to humanity and doing what he's doing. He's obviously a great engineer, and if he works hard, he might undo the wrong of releasing git into the world.
    - taeric 12y ago
      Huh? Since the comparison would be to the likes of svn and cvs, git is a hella good improvement. If you are willing to learn what it is that it does, git is actually fairly frigg'n good. Of course, mayhap I've just not used a better tool.
    - lytol 12y ago
      > he might undo the wrong of releasing git into the world I've never seen a comment with which I more vehemently disagree.
    - jeffreyrogers 12y ago
      I can't tell if you're joking or not. The popularity of GitHub and its position as the defacto modern source control management tool demonstrate that very few people hold your point of view. Sure, Git has a lot of options, but what do you need to actually be productive with Git? Probably only a handful of commands: git clone, git pull, git push, git commit, git add, git checkout, git branch, git log. And not too much more than that. At my university Git is used in every single lab based CS course and I don't know of a single person who has had trouble learning to use it.
      - scotth 12y ago
- gwern 12y ago
  > Because let's face it, even if the kernel build process was some super-efficient thing, real life isn't that anyway. I guarantee you that the "tons of small scripts etc" that the kernel build does is a real load somewhere totally unrelated. Optimizing page faults will help other loads. This is true as far as it goes, but a silly argument. Let's apply a reversal test (http://www.nickbostrom.com/ethics/statusquo.pdf‎ http://www.nickbostrom.com/ethics/statusquo.pdf‎). Suppose the kernel build were as efficient as Chrome's is claimed to be on this page (<5s) and wasn't stressing his system. Would Linus then approve of anyone submitting patches to deliberately slow down the Linux kernel build just to show up slownesses in page fault and encourage kernel devs to spend time on optimizing that? No, of course not! That would be idiocy and the person submitting the patches would probably be banned by Linus in his titanic rage. However, since the slow build & page faults is the status quo, Linus is making lemonade of it...
  - sp332 12y ago
    Not sure why, but your URL has a bunch of junk on the end of it. I don't get what you're arguing against. Even if the kernel were superfast, there's probably another "real load" out there somewhere that legitimately runs into lots of page faults.
    - loup-vaillant 12y ago
      It's a question of what should be addressed first. Linus is actively arguing against a faster kernel build. It sounds like it makes sense, because it gives him leverage with CPU vendors. But it doesn't, really. If kernel build were already fast, he would never in a million years slow it down just to get that leverage. Now maybe he's perfectly aware of this status quo bias, and he's taking advantage of it to meliorate something he would otherwise have no power over. Sneaky. Still, what's the priority? He's made his point now, hasn't he? He could work on making a faster build process, now.
      - Dylan16807 12y ago
        Slowing it down wouldn't give him the same leverage that it has as a real use case. Anyway he's not saying slowness is better in and of itself, just that there are better places to work on than replacing make.
mnw21cam 12y ago
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.
- evmar 12y ago
  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.)
  - mnw21cam 12y ago
    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.
    - stas321 12y ago
      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
  - vidarh 12y ago
    > 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.
asb 12y ago
Just needs someone to grab a Python Makefile parser (e.g. http://benjamin.smedbergs.us/pymake/ http://benjamin.smedbergs.us/pymake/), a python KConfig lib (e.g. https://github.com/ulfalizer/Kconfiglib https://github.com/ulfalizer/Kconfiglib though I guess this isn't really necessary) and write a ninja generator for the kernel build system.
- brokenparser 12y ago
  Web dev here. There should be a gulp plugin for that.
  - paulannesley 12y ago
    shudder. Node.js-powered linux kernel builds? One small step towards https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... coming true ;)
- drothlis 12y ago
  "Just". The "mostly" in pymake's tagline (below) is the tricky bit. pymake: A mostly GNU-compatible python implementation of `make`.

by evmar 12y ago

josephg 12y ago

From further down in the comment thread, Linus says that speeding this up should help other workloads too, and he's sick of using make replacements: --- +Peter oh, it's absolutely true that 'make' is a pig, and does too much, and we don't exactly help the situation by using tons of GNU make features and complex variables and various random shell escapes etc etc. So there's no question that some "makefile compiler" could optimize this all. But quite frankly, I've had my fill of random make replacements. imake, cmake, qmake, they all solve some problem, and they all have their own quirks and idiocies. So while I'd love for 'make' to be super-efficient, at the same time I'd much rather optimize the kernel to do what make needs really well, and have CPU's that don't take too long either. Because let's face it, even if the kernel build process was some super-efficient thing, real life isn't that anyway. I guarantee you that the "tons of small scripts etc" that the kernel build does is a real load somewhere totally unrelated. Optimizing page faults will help other loads.

danudey 12y ago
Maybe he'll get so fed up with make that he'll write his own that everyone can just switch to instead of all the crud we have.
- tedks 12y ago
  Oh no. Not on your life. It would be better for the entire world if Linus had a heart attack rather than rewriting Make. Make is already unusable; git-style make would be an abomination. Can you even imagine reading the man pages of all the different git-make commands? The syntax? I hope Linus keeps contributing to humanity and doing what he's doing. He's obviously a great engineer, and if he works hard, he might undo the wrong of releasing git into the world.
  - taeric 12y ago
    Huh? Since the comparison would be to the likes of svn and cvs, git is a hella good improvement. If you are willing to learn what it is that it does, git is actually fairly frigg'n good. Of course, mayhap I've just not used a better tool.
  - lytol 12y ago
    > he might undo the wrong of releasing git into the world I've never seen a comment with which I more vehemently disagree.
  - jeffreyrogers 12y ago
    I can't tell if you're joking or not. The popularity of GitHub and its position as the defacto modern source control management tool demonstrate that very few people hold your point of view. Sure, Git has a lot of options, but what do you need to actually be productive with Git? Probably only a handful of commands: git clone, git pull, git push, git commit, git add, git checkout, git branch, git log. And not too much more than that. At my university Git is used in every single lab based CS course and I don't know of a single person who has had trouble learning to use it.
    - scotth 12y ago
gwern 12y ago
> Because let's face it, even if the kernel build process was some super-efficient thing, real life isn't that anyway. I guarantee you that the "tons of small scripts etc" that the kernel build does is a real load somewhere totally unrelated. Optimizing page faults will help other loads. This is true as far as it goes, but a silly argument. Let's apply a reversal test (http://www.nickbostrom.com/ethics/statusquo.pdf‎ http://www.nickbostrom.com/ethics/statusquo.pdf‎). Suppose the kernel build were as efficient as Chrome's is claimed to be on this page (<5s) and wasn't stressing his system. Would Linus then approve of anyone submitting patches to deliberately slow down the Linux kernel build just to show up slownesses in page fault and encourage kernel devs to spend time on optimizing that? No, of course not! That would be idiocy and the person submitting the patches would probably be banned by Linus in his titanic rage. However, since the slow build & page faults is the status quo, Linus is making lemonade of it...
- sp332 12y ago
  Not sure why, but your URL has a bunch of junk on the end of it. I don't get what you're arguing against. Even if the kernel were superfast, there's probably another "real load" out there somewhere that legitimately runs into lots of page faults.
  - loup-vaillant 12y ago
    It's a question of what should be addressed first. Linus is actively arguing against a faster kernel build. It sounds like it makes sense, because it gives him leverage with CPU vendors. But it doesn't, really. If kernel build were already fast, he would never in a million years slow it down just to get that leverage. Now maybe he's perfectly aware of this status quo bias, and he's taking advantage of it to meliorate something he would otherwise have no power over. Sneaky. Still, what's the priority? He's made his point now, hasn't he? He could work on making a faster build process, now.
    - Dylan16807 12y ago
      Slowing it down wouldn't give him the same leverage that it has as a real use case. Anyway he's not saying slowness is better in and of itself, just that there are better places to work on than replacing make.

mnw21cam 12y ago

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.

evmar 12y ago
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.)
- mnw21cam 12y ago
  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.
  - stas321 12y ago
    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
- vidarh 12y ago
  > 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.

asb 12y ago

Just needs someone to grab a Python Makefile parser (e.g. http://benjamin.smedbergs.us/pymake/ http://benjamin.smedbergs.us/pymake/), a python KConfig lib (e.g. https://github.com/ulfalizer/Kconfiglib https://github.com/ulfalizer/Kconfiglib though I guess this isn't really necessary) and write a ninja generator for the kernel build system.

brokenparser 12y ago
Web dev here. There should be a gulp plugin for that.
- paulannesley 12y ago
  shudder. Node.js-powered linux kernel builds? One small step towards https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... coming true ;)
drothlis 12y ago
"Just". The "mostly" in pymake's tagline (below) is the tricky bit. pymake: A mostly GNU-compatible python implementation of `make`.