[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1307452580.2322.252.camel@twins>
Date: Tue, 07 Jun 2011 15:16:20 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Borislav Petkov <bp@...64.org>
Cc: Yong Zhang <yong.zhang0@...il.com>, Borislav Petkov <bp@...en8.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"markus@...ppelsdorf.de" <markus@...ppelsdorf.de>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...e.hu" <mingo@...e.hu>,
"linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:sched/urgent] sched: Fix cross-cpu clock sync on remote
wakeups
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists