summaryrefslogtreecommitdiffstats
path: root/kernel/Kconfig.hz (follow)
Commit message (Collapse)AuthorAgeFilesLines
* sched: high-res preemption tickPeter Zijlstra2008-01-251-0/+2
| | | | | | | | | | | | | | | | Use HR-timers (when available) to deliver an accurate preemption tick. The regular scheduler tick that runs at 1/HZ can be too coarse when nice level are used. The fairness system will still keep the cpu utilisation 'fair' by then delaying the task that got an excessive amount of CPU time but try to minimize this by delivering preemption points spot-on. The average frequency of this extra interrupt is sched_latency / nr_latency. Which need not be higher than 1/HZ, its just that the distribution within the sched_latency period is important. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* [PATCH] HZ: 300Hz supportAlan Cox2006-12-071-5/+15
| | | | | | | | | | | | | | | Fix two things. Firstly the unit is "Hz" not "HZ". Secondly it is useful to have 300Hz support when doing multimedia work. 250 is fine for us in Europe but the US frame rate is 30fps (29.99 blah for pedants). 300 gives us a tick divisible by both 25 and 30, and for interlace work 50 and 60. It's also giving similar performance to 250Hz. I'd argue we should remove 250 and add 300, but that might be excess disruption for now. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] i386: Selectable Frequency of the Timer InterruptChristoph Lameter2005-06-231-0/+46
Make the timer frequency selectable. The timer interrupt may cause bus and memory contention in large NUMA systems since the interrupt occurs on each processor HZ times per second. Signed-off-by: Christoph Lameter <christoph@lameter.com> Signed-off-by: Shai Fultheim <shai@scalex86.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>