On Wed, May 27, 2015 at 10:47:18AM +0200, Pavel Machek wrote:
>
> Distros should not enable this, IMO. But I don't think overhead is
> that big in either case.
Coming back from idle there might not be any cache, and you're adding at
least 1 more cache miss for loading cpu_trig -- those hurt. Look
On Wed 2015-05-27 10:08:31, Peter Zijlstra wrote:
> On Wed, May 27, 2015 at 09:47:57AM +0200, Pavel Machek wrote:
> > On Wed 2015-05-27 09:43:43, Peter Zijlstra wrote:
> > > On Wed, May 27, 2015 at 08:57:12AM +0200, Pavel Machek wrote:
> > > >
> > > > CPU LED trigger hooks are currently hidden in
On Wed, May 27, 2015 at 09:47:57AM +0200, Pavel Machek wrote:
> On Wed 2015-05-27 09:43:43, Peter Zijlstra wrote:
> > On Wed, May 27, 2015 at 08:57:12AM +0200, Pavel Machek wrote:
> > >
> > > CPU LED trigger hooks are currently hidden in arm-specific code, which
> > > means that this trigger only
On Wed 2015-05-27 09:43:43, Peter Zijlstra wrote:
> On Wed, May 27, 2015 at 08:57:12AM +0200, Pavel Machek wrote:
> >
> > CPU LED trigger hooks are currently hidden in arm-specific code, which
> > means that this trigger only works on arm. Add it to the generic
> > code, so that it works on x86, t
On Wed, May 27, 2015 at 08:57:12AM +0200, Pavel Machek wrote:
>
> CPU LED trigger hooks are currently hidden in arm-specific code, which
> means that this trigger only works on arm. Add it to the generic
> code, so that it works on x86, too.
And why do we want to go and slow down the idle loop fo
CPU LED trigger hooks are currently hidden in arm-specific code, which
means that this trigger only works on arm. Add it to the generic
code, so that it works on x86, too.
Signed-off-by: Pavel Machek
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index fefcb1f..087acd6 100644
--- a/kern
6 matches
Mail list logo
