Lines Matching refs:and

1 This document explains the thinking about the revamped and streamlined
4 Nice levels were always pretty weak under Linux and people continuously
9 support was historically coupled to timeslice length, and timeslice
13 much stronger than they were before in 2.4 (and people were happy about
14 that change), and we also intentionally calibrated the linear timeslice
43 millisec) rescheduling. (and would thus trash the cache, etc. Remember,
44 this was long ago when hardware was weaker and caches were smaller, and
48 right minimal granularity - and this translates to 5% CPU utilization.
50 and we never got a single complaint about nice +19 being too _weak_ in
55 within the constraints of HZ and jiffies and their nasty design level
56 coupling to timeslices and granularity it was not really viable.
74 and another task with +2, the CPU split between the two tasks would
80 run audio (and other multimedia) apps under RT priorities such as
82 proof, and a buggy SCHED_FIFO app can also lock up the system for good.
87 enough), the scheduler was decoupled from 'time slice' and HZ concepts
88 (and granularity was made a separate concept from nice levels) and thus
89 it was possible to implement better and more consistent nice +19
97 scheduler, running a nice +10 and a nice 11 task has the same CPU
98 utilization "split" between them as running a nice -5 and a nice -4
105 and forcing audio apps to run under the more dangerous SCHED_FIFO