Re: [PATCH] Faster scheduler and separate RT run queue

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 30 Sep 1998 15:25:05 +1000

Linus Torvalds writes:
>
>
> On 30 Sep 1998, Michael O'Reilly wrote:
> >
> > And what does it do to the common case? It looks like it makes it
> > slower... This patch is adding a fair whack of extras..
>
> It shouldn't need to make it slower: it should actually speed up one of
> the most critical paths in the scheduler, which is the "goodness()"
> function. By having a separate RT queue, the goodness() function no longer
> needs to care.
>
> So I don't think it's that obvious.

Agreed. I've done some further testing and the difference is pretty
marginal. Some of the earlier number I quoted compared the rtqueue
patch to a fixed version of 2.1.122 for POSIX.4 compliance. I've now
tested with 2.1.123 plus a revised fix (the same fix that comes with
the rtqueue patch), and the earlier improvements I quoted aren't as
large.

So, comparing apples with apples, I'm seeing up to 0.3 us improvement
(no extra processes on the run queue).

In only one case (SCHED_OTHER thread switching with no extra
processes) do I see a slowdown, and it's only 0.1 us, and that
measurement is pretty marginal anyway. It's probably more likely 0.05
us given the way the numbers vary.
Doing process switching instead (the general case) yields a 0.1 us
improvement. This measurement wasn't marginal.

So, in summary, the worst case cost is tiny, the general case yields a
small but measurable advantage, and the special case (RT) yields a
considerable advantage.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/