More changes for 2.6.16

More changes for 2.6.16

The "infinitely lower priority" scheduling policy would be SCHED_IDLE. The problem with SCHED_IDLE is that i've yet to see a correct implementation.

There are implementations that seem to work for users, but they dont handle one crutial thing: they dont prevent a SCHED_IDLE task from DoS-ing the kernel by holding some critical resource. [*]

E.g. you start a SCHED_IDLE task, it does some processing, calls the kernel and acquires /tmp's inode->i_mutex and gets scheduled away while holding that mutex. If at that point some other, non-SCHED_IDLE CPU-intensive task is started, it will delay the SCHED_IDLE task indefinitely - which task is holding a crutial mutex! No other task will be able to access /tmp, the system will be essentially DoS-ed.

"Infinitely lower priority" scheduling inevitably leads to "infinitely long scheduling latencies", which inevitably leads to totally new scheduling phenomenons that you wont see with the stock scheduler. That's why i implemented the simpler but obviously correct SCHED_BATCH variant. If you want some really non-intrusive processing, set the task to SCHED_BATCH and set its nice level to +19.

[*] years ago i implemented a SCHED_IDLE variant that correctly handles the DoS issue, but it was too intrusive: it needed to hook into the syscall entry and exit path, to set/restore the priority of the SCHED_IDLE task to/from a non-starving priority while it's in kernel mode, to guarantee that kernel mode does not starve.