Messages in this thread | | | Date | Thu, 21 Nov 2013 08:07:16 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations |
| |
On Thu, Nov 21, 2013 at 09:21:51AM +0100, Peter Zijlstra wrote: > 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@infradead.org> 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 ;-)
As long as RCU has some reliable way to identify an idle task, I am good. But I have to ask -- why can't idle injection coordinate with the existing idle tasks rather than temporarily making alternative idle tasks?
Thanx, Paul
> > 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. >
| |