Re: Is it bad to have lots of sleeping tasks?

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> Alan is right, I would not be too concerned about the recalculate
> loop. There are patches out that would basically eliminate the
> update of all tasks during recalculate, but they come at an additional
> cost during add_from_runqueue and del_from_runqueue. I don't know
> exactly where the break-even point is where either solution is
> worse of better.

The overhead will be pretty close to zero since the update will be for a
task that is in local cache, so its a tiny bit of math from L1 cache with
writes that don't cause stalls.

> We presented this stuff at OLS and since then have improved the
> low running-thread count scenario.

> The MQ is functionally equivalent to the current scheduler

This is one of the things I think we have wrong although I understand
keeping the behaviour was part of the goal of your code. The scheduler
should be cache optimising for cpu soakers at least. That also seems
to simplify the scheduler not make it more complex.

For example we tend to schedule events badly - consider processes A and B
and are CPU suckers and an editor. Each time you hit a key and wake the
editor you tend to flip between running A and B. 

I'd like to see us end up with an O(1) [for hardware ffz at least] scheduler
that did the right things for cache locality. I've got some ideas but I
don't know how to make them work SMP.

> Alan, could you suggest some benchmarks to run for 2-way systems,
> that have low thread counts, are easily reproducable (no big setup and
> large system configuration required) that would help us make the point
> for a larger set of application then we have targetted.

Lmbench can be useful for small scale numbers, although it isnt intended
currently to measure SMP. Perhaps Larry can comment on that.

We certainly both agree the scheduler needs work

Alan