[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080531071817.GB5405@ucw.cz>
Date: Sat, 31 May 2008 09:18:18 +0200
From: Pavel Machek <pavel@....cz>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
linux-rt-users <linux-rt-users@...r.kernel.org>, akpm@...l.org,
Ingo Molnar <mingo@...e.hu>,
Clark Williams <clark.williams@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
Gregory Haskins <ghaskins@...ell.com>, Andi Kleen <ak@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] x86: enable preemption in delay
On Wed 2008-05-28 09:01:06, Steven Rostedt wrote:
>
>
> On Sun, 25 May 2008, Pavel Machek wrote:
> > > + if (unlikely(cpu != smp_processor_id())) {
> > > + if (loops <= TSC_MIGRATE_COUNT)
> > > + break;
> > > + cpu = smp_processor_id();
> > > + rdtscl(bclock);
> > > + loops -= TSC_MIGRATE_COUNT;
> > > + } else {
> > > + rdtscl(now);
> > > + if ((now - bclock) >= loops)
> > > + break;
> > > + loops -= (now - bclock);
> > > + bclock = now;
> >
> > What happens with different cpus running on different frequencies...?
> > Cpufreq?
>
> It's not even protected with the old code.
Maybe, but it is simple to fix as long as preemption is disabled. When
you enable it, it becomes much harder.
Lets get that fixed.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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