lkml.org 
[lkml]   [2004]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handling bugs
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.100 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site