RE: a joint letter on low latency and Linux

[Roger Larsson]

(3:rd reply attempt...)

Hi,

I probably did not read the draft well enough...

> However, it turns out, as best we can gather, that you were not happy
> with the basic structure of some or all of Ingo's low latency
> work. Our impression is that you want to see more careful code design
> that avoids interrupt disabling or holding high level locks for too
> long, rather than using preemption points.  So, as far as we can tell
> right now, 2.4 will represent more of the same as far as low latency
> limitations, and for us, more of the same means performance much worse
> than Windows or MacOS present.

This is not the problem.

The problem is that after a process has entered kernel it won't be rescheduled
until it leaves (for kernel threads until it voluntarily reschedules).
During the time it executes in kernel interrupts happens that wakes a higher
priority process but it will not be able to run until the process currently running
in kernel goes to sleep / leaves kernel.

Ingo's patch inserted checks if a higher prio process was waiting in paths that
might become long - list traversals, memory copy, ...

   if (current->need_resched) schedule()

At these points it is important NOT to have interrupts disabled NOR any lock
held as that would lead to deadlocks...

PS,
  there are code that does this in the current kernel - check linux/mm/vmscan.c
  function kswapd
DS

/RogerL