Shachar Shemesh <[email protected]> writes: > Yes. One of the things said about CFS was that with it things that > previously required real time priority now can run at nice -20 just > as well. That same text (I don't remember right now where I read > it, nor who wrote it) said that CFS fixed a nice anomality that used > to exist with O(1).
I am not sure what this refers to, so no comment. > Apparently, two adjacent nice levels are supposed to have a more or > less fixed CPU spread between them, no matter what the absolute nice > level is (the article suggested that if the system has just two > processes, one at nice level X and another at nice X+1, then the CPU > should be divided 45-55 between them). OK, first, we know that niceness and priority are one and the same thing, niceness being just priority relative to default priority (120). So, how is CPU time divided between processes of different priority/niceness (with SCHED_NORMAL=SCHED_OTHER=SCHED_FAIR policy, not real-time)? In O(1) the size of a time slice given to a process scaled with priority. This seems to be the effect you are describing. See below. > It was suggested that O(1) had non-linear nice graph, due to the > tricks played to make nice -20 approximate what it should do. I recall that there were multiple reasons why this scaling should be non-linear. One reason was precisely what you point to: a fixed ratio between CPU utilization between processes at adjacent nice levels. In O(1), the timeslice values were fixed, leading to a non-constant (or, rather, priority-dependent) CPU utilization ratios. In other words, the utilization ratio between a process at priority P and a process at priority P+1 depended on P. This was considered a weakness. I actually think that there was more controversy about nice +19 than about nice -20: what should the minimal timeslice be? how much CPU should a process at nice +19 get? was it too much? does it get a different *percentage* of CPU time at different CPU speeds and loads? There were similar/mirror complaints about nice -20 - were those processes given enough CPU? CFS decouples priorities from the clock and gets rid of timeslices. This makes it possible to 1) give nice +19 processes a fixed percentage of CPU time; 2) make the CPU time split between P and P+1 independent of P (I think this is where 55%/45% comes from); 3) processes with negative niceness get enough CPU. All of the above works because everything is relative now, independently of HZ, timeslices, etc. Hope it helps, -- Oleg Goldshmidt | [email protected] _______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
