1. 15 Nov, 2013 1 commit
  2. 28 Jul, 2008 1 commit
  3. 23 Jul, 2008 1 commit
    • Ingo Molnar's avatar
      sched: fix hrtick & generic-ipi dependency · 422037ba
      Ingo Molnar authored
      Andrew Morton reported this s390 allmodconfig build failure:
      
       kernel/built-in.o: In function `hrtick_start_fair':
       sched.c:(.text+0x69c6): undefined reference to `__smp_call_function_single'
      
      the reason is that s390 is not a generic-ipi SMP platform yet, while
      the hrtick code relies on it. Fix the dependency.
      Signed-off-by: 's avatarIngo Molnar <mingo@elte.hu>
      422037ba
  4. 20 Jul, 2008 1 commit
    • Peter Zijlstra's avatar
      sched, x86: clean up hrtick implementation · 31656519
      Peter Zijlstra authored
      random uvesafb failures were reported against Gentoo:
      
        http://bugs.gentoo.org/show_bug.cgi?id=222799
      
      and Mihai Moldovan bisected it back to:
      
      > 8f4d37ec is first bad commit
      > commit 8f4d37ec
      > 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: 's avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: 's avatarMihai Moldovan <ionic@ionic.de>
      Cc: Michal Januszewski <spock@gentoo.org>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Signed-off-by: 's avatarIngo Molnar <mingo@elte.hu>
      31656519
  5. 25 Jan, 2008 1 commit
    • Peter Zijlstra's avatar
      sched: high-res preemption tick · 8f4d37ec
      Peter Zijlstra authored
      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: 's avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: 's avatarIngo Molnar <mingo@elte.hu>
      8f4d37ec
  6. 07 Dec, 2006 1 commit
    • Alan Cox's avatar
      [PATCH] HZ: 300Hz support · 40fcfc87
      Alan Cox authored
      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: 's avatarAlan Cox <alan@redhat.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      40fcfc87
  7. 23 Jun, 2005 1 commit