Re: [PATCH 3/7] idle, thermal, acpi: Remove home grown idleimplementations

[Peter Zijlstra]

On Wed, Nov 20, 2013 at 04:54:06PM -0800, Jacob Pan wrote:
> On Wed, 20 Nov 2013 17:04:53 +0100
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
> > People are starting to grow their own idle implementations in various
> > disgusting ways. Collapse the lot and use the generic idle code to
> > provide a proper idle cycle implementation.
> > 
> +Paul
> 
> RCU and others rely on is_idle_task() might be broken with the
> consolidated idle code since caller of do_idle may have pid != 0.
> 
> Should we use TS_POLL or introduce a new flag to identify idle task?

PF_IDLE would be my preference, I checked and we seem to have a grand
total of 2 unused task_struct::flags left ;-)

> The reason why idle injection code does not inform RCU is that we have
> known short period of idle time which does not impact RCU grace period.
> 
> On the other side, I see idle injection code is working with this
> patchset with workaround in s_idle_task() by checking TS_POLL flag.
> But the efficiency is down by ~30%. i.e.
> 
> before: inject 25% time to get 23-24% package idle
> after: inject 25% time to get 16-17% package idle
> 
> Still looking into improvement.

So the quick hack is to make acpi_idle/intel_idle use the highest
possible C-state when pid!=0 && PF_IDLE.

Ideally though I'd see some of the QoS ramifications explored. Because
forcing the CPU into the highest C-state basically invalidates the
entire QoS stack.

So either make QoS and this idle injection stuff mutually exclusive in a
very explicit way -- disable the QoS interface when you enable one of
these idle injectors AND fail to engage the idle injectors when an
incompatible QoS setting is pre-existing.

Or come up with something smarter.

You also have to explore the case of higher priority tasks messing with
the proper operation of your injectors, this one is harder to deal with.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/