[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100424162036.47cba620@infradead.org>
Date: Sat, 24 Apr 2010 16:20:36 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Saravana Kannan <skannan@...eaurora.org>,
cpufreq <cpufreq@...r.kernel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Dave Jones <davej@...hat.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
Thomas Renninger <trenn@...e.de>, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: CPUfreq - udelay() interaction issues
On Sat, 24 Apr 2010 17:00:42 -0400
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> > Case 2: multi core or HT, TSC is variable with CPU frequency.
> > This is the really sucky case, since logical CPU 0's tsc frequency
> > in part depends on what logical CPU 1 will do etc. No good answer
> > for this other than assuming the worst. Based on your document
> > these do actually exist in early P4 cpus.
>
> Keeping track of the cpu frequency changes can help here. Along with
> periodic resynchronization if cpu clocks drift too far apart. I've
> done that for the LTTng omap3 trace clock.
it's not enough; voting does not work that way.
the way voting ends up working is that the hardware runs the maximum of
the various frequency requests ... but for the threads that are not
idle.
so if cpu 1 goes to a high frequency, cpu 0 goes up to.. until cpu 1
goes idle; then only cpu 0's value is in use.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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