Re: O(1) count_active_tasks()

William Lee Irwin III (wli@holomorphy.com)
Sun, 26 May 2002 16:03:19 -0700


On Sat, 2002-05-25 at 20:51, William Lee Irwin III wrote:
>> rml, I heard you're interested in this, but regardless, here it is.
>> AFAICT it computes a faithful load average. Against latest 2.5.18 bk.
>> rml, don't worry about stomping on this if you need the counters
>> ticking for something else and you can do the same thing(s).

On Sun, May 26, 2002 at 03:17:52PM -0700, Robert Love wrote:
> I like. Very clean.

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).

On Sun, May 26, 2002 at 03:17:52PM -0700, Robert Love wrote:
> One question...
>> rq = task_rq_lock(p, &flags);
>> + if (p->state == TASK_UNINTERRUPTIBLE)
>> + uninterruptible = 1;
>> p->state = TASK_RUNNING;
>> if (!p->array) {
>> + if (uninterruptible)
>> + rq->nr_uninterruptible--;
>> activate_task(p, rq);
>> if (p->prio < rq->curr->prio)
>> resched_task(rq->curr);
>
> Why only decrement nr_uninterruptible if it is not already on a
> runqueue? I suspect because then you assume it is a spurious wakeup and
> did not have a corresponding deactivate_task? Same reason we increment
> nr_running in activate_task and not here, I suspect... makes sense.

When it was not there load averages were dramatically unfaithful, and I
traced down the cause of that to this branch.

On Sun, May 26, 2002 at 03:17:52PM -0700, Robert Love wrote:
> One thought on a quick way to test if the new method is returning
> accurate results would be to leave the current count_active_task code
> and then add:
> if (nr != (nr_running() + nr_uninterruptible()))
> printk("Danger Will Robinson!\n");
> but you probably already did something similar.
> Robert Love

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.

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.

Thanks,
Bill
-
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/