Re: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handling bugs

[Peter Williams <pwil3058@bigpond.net.au>]

Ingo Molnar wrote:
> * Peter Williams <pwil3058@bigpond.net.au> wrote:
> 
> 
>>Couldn't this part of the problem have been solved by using an
>>atomic_t for nr_uninterruptible as for nr_iowait?  It would also
>>remove the need for migrate_nr_uninterruptible().
> 
> 
> maybe, but why? Atomic ops are still a tad slower than normal ops and
> every cycle counts in the wakeup path. Also, the solution is still not
> correct, because it does not take other migration paths into account, so

Oops.

> we could end up with a sleeping task showing up on another CPU just as
> well. The most robust solution is to simply not care about migration and
> to care about the total count only.

Yes and, with the new comment above its declaration, if anybody (in the 
future) wants to use the per cpu data they will be aware that they need 
to modify the code if they need it to be always accurate.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce