On Tue, 2011-06-07 at 15:12 +0200, Borislav Petkov wrote: > On Thu, Jun 02, 2011 at 11:48:31AM -0400, Peter Zijlstra wrote: > > Crap.. you're right. And I bet other archs don't do that either. With > > NO_HZ you really need irq_enter() for pretty much all interrupts so I > > was assuming the resched IPI had it, but its been special and never > > really needed it. If it would wake an idle cpu the idle loop exit would > > deal with it, if it interrupted userspace the thing was running and > > NO_HZ wasn't relevant. > > > > Damn. > > > > And yes, the only reason I didn't see this on my dev box was because we > > do indeed set that sched_clock_stable thing on wsm. And I never noticed > > on my desktop because firefox/X/etc. consuming heaps of CPU isn't weird > > at all. > > > > Adding it to all resched int handlers is of course a possibility but > > would slow down the thing, although with the new code, most users are > > now indeed wakeups (excepting weird and wonderful users like KVM). > > FWIW, we could set the sched_clock_stable on AMD too - at least on F10h > and later. This will take care of the problem at hand and defer the > issue of slowing down the resched ipi handlers. > > I dunno, however, whether we still would need the proper ->tick_gtod > update for correct ttwu accounting regardless of sched_clock_stable on > K8 (unstable TSCs) and maybe even other arches. Yeah, I think I'm going to commit this extra irq_enter() thing for now, and then slowly go through all the arches again and remove this one here once all archs are sorted. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|