2013/3/25 Peter Zijlstra :
> On Fri, 2013-03-22 at 14:54 +0100, Frederic Weisbecker wrote:
>> And I have to say this patch is going to be very useful for the full
>> dynticks tree. We are happy to get rid of that tick hook.
>
> I'm sorry to have to disappoint, but the tick hook is still there ;-),
On Fri, 2013-03-22 at 14:54 +0100, Frederic Weisbecker wrote:
> And I have to say this patch is going to be very useful for the full
> dynticks tree. We are happy to get rid of that tick hook.
I'm sorry to have to disappoint, but the tick hook is still there ;-),
its just no longer used for counte
On Fri, Mar 22, 2013 at 6:33 PM, Andi Kleen wrote:
>
> On Fri, Mar 22, 2013 at 11:51:37AM +0100, Stephane Eranian wrote:
> > The current scheme of using the timer tick was fine
> > for per-thread events. However, it was causing
> > bias issues in system-wide mode (including for
> > uncore PMUs). E
On Fri, Mar 22, 2013 at 11:51:37AM +0100, Stephane Eranian wrote:
> The current scheme of using the timer tick was fine
> for per-thread events. However, it was causing
> bias issues in system-wide mode (including for
> uncore PMUs). Event groups would not get their
> fair share of runtime on the P
2013/3/22 Stephane Eranian :
> The current scheme of using the timer tick was fine
> for per-thread events. However, it was causing
> bias issues in system-wide mode (including for
> uncore PMUs). Event groups would not get their
> fair share of runtime on the PMU. With tickless
> kernels, if a cor
The current scheme of using the timer tick was fine
for per-thread events. However, it was causing
bias issues in system-wide mode (including for
uncore PMUs). Event groups would not get their
fair share of runtime on the PMU. With tickless
kernels, if a core is idle there is no timer tick,
and thu
6 matches
Mail list logo
