forked from Minki/linux
31656519e1
random uvesafb failures were reported against Gentoo: http://bugs.gentoo.org/show_bug.cgi?id=222799 and Mihai Moldovan bisected it back to: >8f4d37ec07is first bad commit > commit8f4d37ec07> 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>
59 lines
1.6 KiB
Plaintext
59 lines
1.6 KiB
Plaintext
#
|
|
# Timer Interrupt Frequency Configuration
|
|
#
|
|
|
|
choice
|
|
prompt "Timer frequency"
|
|
default HZ_250
|
|
help
|
|
Allows the configuration of the timer frequency. It is customary
|
|
to have the timer interrupt run at 1000 Hz but 100 Hz may be more
|
|
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
|
|
100 Hz is a typical choice for servers, SMP and NUMA systems
|
|
with lots of processors that may show reduced performance if
|
|
too many timer interrupts are occurring.
|
|
|
|
config HZ_250
|
|
bool "250 HZ"
|
|
help
|
|
250 Hz is a good compromise choice allowing server performance
|
|
while also showing good interactive responsiveness even
|
|
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.
|
|
|
|
config HZ_1000
|
|
bool "1000 HZ"
|
|
help
|
|
1000 Hz is the preferred choice for desktop systems and other
|
|
systems requiring fast interactive responses to events.
|
|
|
|
endchoice
|
|
|
|
config HZ
|
|
int
|
|
default 100 if HZ_100
|
|
default 250 if HZ_250
|
|
default 300 if HZ_300
|
|
default 1000 if HZ_1000
|
|
|
|
config SCHED_HRTICK
|
|
def_bool HIGH_RES_TIMERS
|