kevin/linux
1
Fork 0
Code
31656519e1
linux/kernel/Kconfig.hz

59 lines
1.6 KiB
Plaintext
Raw Normal View History

[PATCH] i386: Selectable Frequency of the Timer Interrupt 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>
2005-06-23 00:08:25 -07:00
#
# Timer Interrupt Frequency Configuration
#
choice
prompt "Timer frequency"
default HZ_250
help
Allows the configuration of the timer frequency. It is customary
[PATCH] HZ: 300Hz support 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>
2006-12-06 21:37:27 -07:00
to have the timer interrupt run at 1000 Hz but 100 Hz may be more
[PATCH] i386: Selectable Frequency of the Timer Interrupt 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>
2005-06-23 00:08:25 -07:00
beneficial for servers and NUMA systems that do not need to have
a fast response for user interaction and that may experience bus
contention and cacheline bounces as a result of timer interrupts.
Note that the timer interrupt occurs on each processor in an SMP
environment leading to NR_CPUS * HZ number of timer interrupts
per second.
config HZ_100
bool "100 HZ"
help
[PATCH] HZ: 300Hz support 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>
2006-12-06 21:37:27 -07:00
100 Hz is a typical choice for servers, SMP and NUMA systems
[PATCH] i386: Selectable Frequency of the Timer Interrupt 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>
2005-06-23 00:08:25 -07:00
with lots of processors that may show reduced performance if
too many timer interrupts are occurring.
config HZ_250
bool "250 HZ"
help
[PATCH] HZ: 300Hz support 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>
2006-12-06 21:37:27 -07:00
250 Hz is a good compromise choice allowing server performance
[PATCH] i386: Selectable Frequency of the Timer Interrupt 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>
2005-06-23 00:08:25 -07:00
while also showing good interactive responsiveness even
[PATCH] HZ: 300Hz support 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>
2006-12-06 21:37:27 -07:00
on SMP and NUMA systems. If you are going to be using NTSC video
or multimedia, selected 300Hz instead.
config HZ_300
bool "300 HZ"
help
300 Hz is a good compromise choice allowing server performance
while also showing good interactive responsiveness even
on SMP and NUMA systems and exactly dividing by both PAL and
NTSC frame rates for video and multimedia work.
[PATCH] i386: Selectable Frequency of the Timer Interrupt 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>
2005-06-23 00:08:25 -07:00
config HZ_1000
bool "1000 HZ"
help
[PATCH] HZ: 300Hz support 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>
2006-12-06 21:37:27 -07:00
1000 Hz is the preferred choice for desktop systems and other
[PATCH] i386: Selectable Frequency of the Timer Interrupt 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>
2005-06-23 00:08:25 -07:00
systems requiring fast interactive responses to events.
endchoice
config HZ
int
default 100 if HZ_100
default 250 if HZ_250
[PATCH] HZ: 300Hz support 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>
2006-12-06 21:37:27 -07:00
default 300 if HZ_300
[PATCH] i386: Selectable Frequency of the Timer Interrupt 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>
2005-06-23 00:08:25 -07:00
default 1000 if HZ_1000
sched: high-res preemption tick 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>
2008-01-25 13:08:29 -07:00
config SCHED_HRTICK
sched, x86: clean up hrtick implementation random uvesafb failures were reported against Gentoo: http://bugs.gentoo.org/show_bug.cgi?id=222799 and Mihai Moldovan bisected it back to: > 8f4d37ec073c17e2d4aa8851df5837d798606d6f is first bad commit > commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f > Author: Peter Zijlstra <a.p.zijlstra@chello.nl> > Date: Fri Jan 25 21:08:29 2008 +0100 > > sched: high-res preemption tick Linus suspected it to be hrtick + vm86 interaction and observed: > Btw, Peter, Ingo: I think that commit is doing bad things. They aren't > _incorrect_ per se, but they are definitely bad. > > Why? > > Using random _TIF_WORK_MASK flags is really impolite for doing > "scheduling" work. There's a reason that arch/x86/kernel/entry_32.S > special-cases the _TIF_NEED_RESCHED flag: we don't want to exit out of > vm86 mode unnecessarily. > > See the "work_notifysig_v86" label, and how it does that > "save_v86_state()" thing etc etc. Right, I never liked having to fiddle with those TIF flags. Initially I needed it because the hrtimer base lock could not nest in the rq lock. That however is fixed these days. Currently the only reason left to fiddle with the TIF flags is remote wakeups. We cannot program a remote cpu's hrtimer. I've been thinking about using the new and improved IPI function call stuff to implement hrtimer_start_on(). However that does require that smp_call_function_single(.wait=0) works from interrupt context - /me looks at the latest series from Jens - Yes that does seem to be supported, good. Here's a stab at cleaning this stuff up ... Mihai reported test success as well. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Tested-by: Mihai Moldovan <ionic@ionic.de> Cc: Michal Januszewski <spock@gentoo.org> Cc: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-18 09:01:23 -07:00
def_bool HIGH_RES_TIMERS
Copy Permalink