4 ms·

A standard test for scheduler responsiveness in Linux is to fire up a kernel compile with unlimited jobs[0]. If responsiveness is lost, the scheduler isn't read

A standard test for scheduler responsiveness in Linux is to fire up a kernel compile with unlimited jobs[0]. If responsiveness is lost, the scheduler isn't ready for prime time. You think Microsoft wants the answer to this issue to be "we can't even match Linux"? [0] Well, it used to be. I assume they've moved on to more demanding tests now, since hardware has far outstripped kernel build complexity.

bhouston 13y ago
The issue isn't responsiveness during build for me (that isn't usually an issue, my build machine is generally responsive), it is compile performance from start to finish. If you over-allocate to the extreme you will trash your CPU caches and this will slow everything down. You want to minimize CPU context switches (thread switches) while also ensuring that your CPUs are running at nearly 100% -- it is a difficult balance, but unlimited jobs and focusing on the responsiveness of another task is not the solution to maximizing start-to-finish compile time for a large project.
- TorKlingberg 13y ago
  I think the article author is quite aware that too much parallelism will slow down the build, but still wanted too investigate why it makes his computer so unresponsive.
- nknighthb 13y ago
  Speed of build isn't the issue, responsiveness is. Throughput is commonly sacrificed in favor of interactive performance, otherwise we'd all be running some modern equivalent of punchcard batch jobs.
AaronFriel 13y ago
Is this the same thing as with Visual Studio compiling 12 independent projects using 12 threads each? Does the kernel compile with unlimited jobs keep the number of concurrently running jobs below the processor limit, or are additional jobs in any way blocked on cheap primitives, such as waiting for previous jobs with a mutex? The issue here alone is that he was trying to compile 12 projects simultaneously each with every logical processor he has. There might be some slack in the system, but is each project 92% wait time?
- herge 13y ago
  > Does the kernel compile with unlimited jobs keep the number of concurrently running jobs below the processor limit, or are additional jobs in any way blocked on cheap primitives, such as waiting for previous jobs with a mutex? How do you think threads were implemented by the OS back when we all had one processor with one core?
  - AaronFriel 13y ago
    I don't understand your question. I'm asking if the Linux kernel compile with unlimited jobs oversubscribes compute resources in the same way that compiling 12 independent projects does.
  - brianpgordon 13y ago
    He's asking whether the number of jobs is artificially limited to the number of processors, not what happens when the number of jobs is greater than the number of processors.
    - pwg 13y ago
      I believe the only limiter on a 'make -j' is how quickly make can scan directories, stat() the files, and fork() additional compiler instances.
- Danieru 13y ago
  The linux kernel uses a make based build system. When you kickoff a unlimited parallel build with `make -j` you get one gcc process per .c file. As you can imagine this over subscribes the CPU by little bit.
asveikau 13y ago
Sounds a bit like apples and oranges. If in your test GCC happened to stall because of a bug in some shared library in user mode, would you blame the scheduler? Maybe this isn't exactly a great argument since I know Linus has been known to take the side of not ever breaking user mode wrt kernel changes (probably rightfully so) but it is possible to write buggy code, including hangs, that runs on Linux. That would be the analogous scenario.
- nknighthb 13y ago
  They're not testing for GCC stalling, they're testing for user interaction stalling -- the same thing the OP is complaining about. Strictly speaking, the direct cause of OP's problem appears to be outside the kernel, but it is system-level. Microsoft has created a stack in which low-priority tasks can trivially destroy the responsiveness of interactive tasks unrelated to the build process.

bhouston 13y ago

The issue isn't responsiveness during build for me (that isn't usually an issue, my build machine is generally responsive), it is compile performance from start to finish. If you over-allocate to the extreme you will trash your CPU caches and this will slow everything down. You want to minimize CPU context switches (thread switches) while also ensuring that your CPUs are running at nearly 100% -- it is a difficult balance, but unlimited jobs and focusing on the responsiveness of another task is not the solution to maximizing start-to-finish compile time for a large project.

TorKlingberg 13y ago
I think the article author is quite aware that too much parallelism will slow down the build, but still wanted too investigate why it makes his computer so unresponsive.
nknighthb 13y ago
Speed of build isn't the issue, responsiveness is. Throughput is commonly sacrificed in favor of interactive performance, otherwise we'd all be running some modern equivalent of punchcard batch jobs.

AaronFriel 13y ago

Is this the same thing as with Visual Studio compiling 12 independent projects using 12 threads each? Does the kernel compile with unlimited jobs keep the number of concurrently running jobs below the processor limit, or are additional jobs in any way blocked on cheap primitives, such as waiting for previous jobs with a mutex? The issue here alone is that he was trying to compile 12 projects simultaneously each with every logical processor he has. There might be some slack in the system, but is each project 92% wait time?

herge 13y ago
> Does the kernel compile with unlimited jobs keep the number of concurrently running jobs below the processor limit, or are additional jobs in any way blocked on cheap primitives, such as waiting for previous jobs with a mutex? How do you think threads were implemented by the OS back when we all had one processor with one core?
- AaronFriel 13y ago
  I don't understand your question. I'm asking if the Linux kernel compile with unlimited jobs oversubscribes compute resources in the same way that compiling 12 independent projects does.
- brianpgordon 13y ago
  He's asking whether the number of jobs is artificially limited to the number of processors, not what happens when the number of jobs is greater than the number of processors.
  - pwg 13y ago
    I believe the only limiter on a 'make -j' is how quickly make can scan directories, stat() the files, and fork() additional compiler instances.
Danieru 13y ago
The linux kernel uses a make based build system. When you kickoff a unlimited parallel build with `make -j` you get one gcc process per .c file. As you can imagine this over subscribes the CPU by little bit.

asveikau 13y ago

Sounds a bit like apples and oranges. If in your test GCC happened to stall because of a bug in some shared library in user mode, would you blame the scheduler? Maybe this isn't exactly a great argument since I know Linus has been known to take the side of not ever breaking user mode wrt kernel changes (probably rightfully so) but it is possible to write buggy code, including hangs, that runs on Linux. That would be the analogous scenario.

nknighthb 13y ago
They're not testing for GCC stalling, they're testing for user interaction stalling -- the same thing the OP is complaining about. Strictly speaking, the direct cause of OP's problem appears to be outside the kernel, but it is system-level. Microsoft has created a stack in which low-priority tasks can trivially destroy the responsiveness of interactive tasks unrelated to the build process.