On Sun, 2002-05-26 at 16:03, William Lee Irwin III wrote:
> Thanks, I took some time to go over it and make it so, as I don't
> really do scheduling, I just needed a statistic there for this. It's
> not actually claimed to have any optimization value (though it may as
> a side-effect), it only addresses a pet peeve of mine. I originally
> tried avoiding sched.c by having set_current_state() tick per-cpu
> counters but that caused enormous code bloat (or did as I wrote it).
Yah, set_current_state is inlined so it would lead to a bit of code
bloat.
> This is an approximate method. I did not collect detailed statistics on
> how widely it varied from the prior method, though I did manually check
> the results against mainline for large variations or gross unfaithfulness.
> If you'd like to hold off on this until I do so, that's fine. I can get
> back to my SMP targets Tuesday and follow up then.
If I get a chance, I'll run some tests on my dual 2.5 machine and see if
they match. But I would not let that stop anything ... this is mergable
in 2.5 imo.
One thing I notice is the patch only increments in one case:
TASK_RUNNING -> TASK_UNINTERRUPTIBLE
whether we ever go -> TASK_UNINTERRUPTIBLE from a state other than
running I am unsure.
> Going back and looking at it, weaker memory consistency models may want
> the increment/decrement to be atomic operations, which would probably
> want some migration code to keep the counters positive. I can arrange
> that for a follow-up as well.
Personally, I would not worry about this. This is only a statistic
after all - I am more interested in whether we are properly accounting
for everything in general. Screw weak memory consistency computers <g>
- they need to fix nr_running too, anyhow.
Robert Love
-
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/
This archive was generated by hypermail 2b29 : Fri May 31 2002 - 22:00:22 EST