Discussion:
Linux gets O(1) scheduler
Perry E. Metzger
2003-12-26 23:23:44 UTC
Permalink
Linux gets O(1) scheduler:
http://www.arstechnica.com/etc/linux/index.html
--
Perry E. Metzger ***@piermont.com
Andrew R. Reiter
2003-12-26 23:49:10 UTC
Permalink
I didn't believe this to be new news. I've used linux on a work embedded
system with mingo's O(1) for a long time now.

On Fri, 26 Dec 2003, Perry E. Metzger wrote:

:
:Linux gets O(1) scheduler:
:http://www.arstechnica.com/etc/linux/index.html
:
:--
:Perry E. Metzger ***@piermont.com
:
:

--
Andrew R. Reiter
***@watson.org
***@FreeBSD.org
Martin Husemann
2003-12-27 00:00:16 UTC
Permalink
Are there any details beyound marketing?

"There is a fixed number of priority levels, so selecting a runnable process
has constant costs" does not realy justify the name.

Martin
Jesper Louis Andersen
2003-12-27 00:51:39 UTC
Permalink
Post by Martin Husemann
Are there any details beyound marketing?
"There is a fixed number of priority levels, so selecting a runnable process
has constant costs" does not realy justify the name.
It does. The question when doing Big Oh notation is what the n is
bound to. I think the n in O(1)-scheduler case is bound to the number
of processes served by the kernel. This makes the number of priorities
to c, which correctly is constant. Keeping an array of run-queues,
we at max need c steps to traverse the whole queue. Ergo, we can
select the next proces in O(c) = O(1) time. Now, where it gets
interesting is in the part where we exhaust the priority array. I think
the scheduler switches to another datastructure it has made ready for
the cause if I do not remember wrongly. So there is 2 arrays running
in parallel, called the working and the restructuring copy. When the
working copy is exhausted we switch.

What is then needed is the change of priority. And this is the non-
trivial part.

I cannot remember what the 44BSD scheduler does, but I remember it
moves long-term sleeping processes out of the calculation altogether.

The FreeBSD people has started to look at the ULE-scheduler which is
an alternative to 44BSD. AFAIR this work is lead by Jeff Roberson,
but I might be wrong. It incorporates a number of things from the
O(1)-scheduler of Linux-fame. They are planning to make it the default
scheduler after 5.2 has been released in order to stress it and see
where it lacks power.
--
j.
Sam Leffler
2003-12-27 01:16:36 UTC
Permalink
Post by Jesper Louis Andersen
The FreeBSD people has started to look at the ULE-scheduler which is
an alternative to 44BSD. AFAIR this work is lead by Jeff Roberson,
but I might be wrong. It incorporates a number of things from the
O(1)-scheduler of Linux-fame. They are planning to make it the default
scheduler after 5.2 has been released in order to stress it and see
where it lacks power.
Who got what from where is unclear, but it's true that some of the performance
claims associated with the Linux scheduler did inspire some of Jeff's work.
Look at Jeff's ULE paper that was presented at the latest BSDCon.

Sam
Jesper Louis Andersen
2003-12-27 01:24:27 UTC
Permalink
Post by Sam Leffler
Who got what from where is unclear, but it's true that some of the
performance claims associated with the Linux scheduler did inspire
some of Jeff's work.
Interesting.
Post by Sam Leffler
Look at Jeff's ULE paper that was presented at the latest BSDCon.
USENIX itself takes a login/password pair for the paper.
It seems there is an available copy at

http://wiki.bsdchat.com/Wiki.jsp?page=PDF

though.

Down the more (insane) scheduler games I've heard about is a
Domain Specific Language for schedulers and runtime change of scheduler.
I might be able to find papers on that if it has interest, but it is
more language-theoretic research than usefullness probably.
--
j.
Martin Husemann
2003-12-27 11:48:34 UTC
Permalink
Ergo, we can select the next proces in O(c) = O(1) time.
Yeah, sure. The interesting question is how much work needs to be done in
advance to manage the different queues. And as you sketched it, the
alternative array. Big oh is nice in the academic world. But at the
scheduler, the details matter. So what would be far more interesting than
a pointer to a news article bringing this up in marketing speech to the
masses, would be a pointer to a paper describing the details.

Martin
Alan Post
2003-12-27 12:08:02 UTC
Permalink
So what would be far more interesting than a pointer to a news
article bringing this up in marketing speech to the masses, would be
a pointer to a paper describing the details.
You might be interested in Jeff Roberson's paper on the FreeBSD 5
scheduler:

http://www.chesapeake.net/~jroberson/ULE.pdf
David Laight
2004-01-04 17:39:27 UTC
Permalink
Post by Martin Husemann
Big oh is nice in the academic world.
But at the scheduler, the details matter.
It might be nice stopping the scheduler looking at every LWP every timer
tick though. The priority of sleeping processes doesn't need to be
recalculated....

If the scheduler only looked at runnable LWPs on each timer tick, it would
make the process lists musch easier to make MP safe.

David
--
David Laight: ***@l8s.co.uk
Martin Husemann
2004-01-04 17:51:58 UTC
Permalink
Post by David Laight
It might be nice stopping the scheduler looking at every LWP every timer
tick though.
Yes, agreed. We knew our scheduler needs a major rewrite for SMP/threading.

I've looked at the ULE paper and it has several interesting points,
of which the "we got rid of some simple data structures from the stone
age that do not scale well today" [i.e. the part O(1) refers to in the Linux
stuff] is only a minor one.

The per physical CPU (ignoring virtual/hyper threaded ones) queues and their
balancing are interesting. I fail to see how the very simple scheme should do
well with scheduling multiple FPU using threads + some non-CPU using ones on
a multi-hyper-threaded-CPU machine though.

Martin
P.S.: I found it funny that the whole paper does not explain the name. I've
never used FreeBSD, so how should I know that options SCHED_4BSD selects the
old scheduler in FreeBSD, while options SCHED_ULE selects the new one.
Martin Husemann
2004-01-04 18:01:27 UTC
Permalink
Post by Martin Husemann
well with scheduling multiple FPU using threads + some non-CPU using ones on
heh, I wish I knew about non-CPU using threads - FPU is what I meant, of
course.

Martin

Perry E. Metzger
2003-12-27 00:15:31 UTC
Permalink
Post by Andrew R. Reiter
I didn't believe this to be new news. I've used linux on a work embedded
system with mingo's O(1) for a long time now.
That's not the point. The point is that NetBSD could use a scheduler
like that.

.pm
Loading...