Messages in this thread | | | Date | Mon, 19 Aug 2013 13:10:26 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 2/4] nohz: Synchronize sleep time stats with seqlock |
| |
On Fri, Aug 16, 2013 at 06:46:28PM +0200, Frederic Weisbecker wrote:
Option A:
> Should we flush that iowait to the src CPU? But then it means we must handle > concurrent updates to iowait_sleeptime, idle_sleeptime from the migration > code and from idle enter / exit. > > So I fear we need a seqlock.
Option B:
> Or we can live with that and still account the whole idle time slept until > tick_nohz_stop_idle() to iowait if we called tick_nohz_start_idle() with nr_iowait > 0. > All we need is just a new field in ts-> that records on which state we entered > idle. > > What do you think?
I think option B is unworkable. Afaict it could basically caused unlimited iowait time. Suppose we have a load-balancer that tries it bestestest to sort-left (ie. run a task on the lowest 'free' cpu possible) -- the power aware folks are pondering such schemes.
Now suppose we have a small burst of activity and the rightmost cpu gets to run something that goes to sleep on iowait.
We'd accrue iowait on that cpu until it wakes up, which could be days from now if the load stays low enough, even though the task got to run almost instantly on another cpu.
So no, if we need per-cpu iowait time we have to do A.
Since we already have atomics in the io_schedule*() paths, please replace those with (seq)locks. Also see if you can place the entire iowait accounting thing in a separate cacheline.
That said, I'm still not sure if iowait time counts as both idle and iowait or only iowait.
| |