On Sat, Oct 06, 2012 at 10:38:34PM +0200, Gregor Best wrote: > Hi Alexandre, > > > [...] > > This change is unclear for me; AFAIU, it removes the mechanism > > which makes processes wake up with a priority depending on what > > they are blocked on. > > [...] > > Where do you see that? The code I removed/changed simply calulated the queue > from > which to remove `p` and removed it from there (similar for insertion). That > needed > to be changed to modify the RB tree used as a new runqueue. > > > [...] > > For instance processes waking up from poll(2) or audio read/write > > won't be prioritized any longer. If so, this would hurt audio and > > other interactive processes but would improve cpu-intesive > > bloatware. > > [...] > > They weren't prioritised with the old version of this code either. >
AFAIU, when a process waits for an event (with tsleep(9)), it provides the priority of the event it's waiting for (eg an audio interrupt). When the event occurs, the process is put in the runnable queue calculated from the priority. This way, interactive processes (i.e. waiting for external events) are prioritized during the event processing. This mechanism ensures audio and midi are usable without having to manually tweak priorities. Furthermore, priorities changed depending on what the process is doing. The most notable exception to above "rule" is the poll(2) implementation, which still ignores priorities; it may need to be fixed one day, but this is not the most urgent problem hurting interactive processes. [A -- Alexandre
