LinSched updated to current linux kernel version

LinSched updated to current linux kernel version

[Jon Tore Hafstad]

 Hi all

I wish to inform you about an update of LinSched (The Linux Scheduler
Simulator([1])) I'm currently working on.

I'm a master's student at NTNU (Norwegian University of Technology and
Science) and writing my project thesis on real-time schedulers. As a
part of this project I've been working on updating LinSched  to the
current version of the linux kernel (2.6.32).

== Motivation ==
I wished to implement different EDF schedulers to gain a better
understanding of kernel internals as well as scheduling dynamics. I
got some feedback from Henrik Austad  that LinSched was a tool that
made implementing a scheduler in to  the linux kernel easier,  since
the code compiles in a fraction of the time the kernel does (Yes, I
know you can pull all sorts of tricks and tweaks in order to speed up
a kernel compilation), a segfault will be a segfault, and not a kernel
oops ;),and the full range of debuggers and memory analyzers will be
available.

The reason for sending this email to you now, is that even though
there still are several unresolved issues, the code is in a
more-or-less stable state and I'd like to let others have a look at it
too.

== Work ==
Thanks to thep way to the orgininal version was made by John M.
Calandrino[1], Dan P. Baumberger, Tong Li [2], Jessica C. Young, and
Scott Hahn. I got a good start and understanding of what would be
necessary to update, to get LinSched runnig with the current linux
kernel.

The main philosophy in LinSched is to keep things as close to the
kernel as possible. Enabling an easier transition from testing
scheduler in LinSched to actually getting it running in the kernel.
Most of the major challenges I have met, has been all the new features
added in the kernel since 2.6.32 such as:
Load balancing for RT tasks.
Group scheduling.

== Remaining Work ==
One of the major issues right now is the hrtimers, which large
portions of the scheduler now use. I have not decided exactly how to
solve this issue yet,but this will be the focus of my work for the
coming weeks.

--
[1]  http://www.cs.unc.edu/~jmc/linsched/
[2] http://happyli.org/tongli/

Regards,

Jon Tore Hafstad

Code can be found at: http://austad.us/jontore/

Re: LinSched updated to current linux kernel version

[Peter Zijlstra]

On Wed, 2009-11-18 at 21:11 +0100, Jon Tore Hafstad wrote:
>  Hi all
> 
> I wish to inform you about an update of LinSched (The Linux Scheduler
> Simulator([1])) I'm currently working on.

> == Motivation ==
> I wished to implement different EDF schedulers to gain a better
> understanding of kernel internals as well as scheduling dynamics. I
> got some feedback from Henrik Austad  that LinSched was a tool that
> made implementing a scheduler in to  the linux kernel easier,  since
> the code compiles in a fraction of the time the kernel does (Yes, I
> know you can pull all sorts of tricks and tweaks in order to speed up
> a kernel compilation), a segfault will be a segfault, and not a kernel
> oops ;),and the full range of debuggers and memory analyzers will be
> available.

I would have expected people to use UML for this (User-Mode-Linux, not
the draw lots of silly pictures thing).

The main draw-back is that UML doesn't currently support SMP and any
interesting preemption modes, but adding that to UML would help out more
people -- I know the VM (virtual Memory, not the machine thing) people
used to use UML for exactly these reasons, easy gdb, etc..

But I suspect that with KVM's gdb stub getting usable more and more
people are abandoning this.

> == Remaining Work ==
> One of the major issues right now is the hrtimers, which large
> portions of the scheduler now use. I have not decided exactly how to
> solve this issue yet,but this will be the focus of my work for the
> coming weeks.

The typical implementation would be signals using the posix timers.

Have the spin_lock_irq variants mask signals etc..

Re: LinSched updated to current linux kernel version

[Henrik Austad]

[-- Attachment #1: Type: Text/Plain, Size: 2068 bytes --]

On Monday 23. November 2009 15.08.15 Peter Zijlstra wrote:
> On Wed, 2009-11-18 at 21:11 +0100, Jon Tore Hafstad wrote:
> >  Hi all
> >
> > I wish to inform you about an update of LinSched (The Linux Scheduler
> > Simulator([1])) I'm currently working on.
> >
> > == Motivation ==
> > I wished to implement different EDF schedulers to gain a better
> > understanding of kernel internals as well as scheduling dynamics. I
> > got some feedback from Henrik Austad  that LinSched was a tool that
> > made implementing a scheduler in to  the linux kernel easier,  since
> > the code compiles in a fraction of the time the kernel does (Yes, I
> > know you can pull all sorts of tricks and tweaks in order to speed up
> > a kernel compilation), a segfault will be a segfault, and not a kernel
> > oops ;),and the full range of debuggers and memory analyzers will be
> > available.
> 
> I would have expected people to use UML for this (User-Mode-Linux, not
> the draw lots of silly pictures thing).

What is the current status of UML - is anyone actually working on that these 
days?

> The main draw-back is that UML doesn't currently support SMP and any
> interesting preemption modes, but adding that to UML would help out more
> people -- I know the VM (virtual Memory, not the machine thing) people
> used to use UML for exactly these reasons, easy gdb, etc..

Well, another drawback of UML is the size. The whole point with LinSched is to 
be *lightweight* while still being accurate. By accurate I mean that code 
written and tested with LinSched should work nearly out of the box when placed 
in the kernel.

LinSched is all about scheduling - nothing else. To be able to compile the 
code in a fraction of a second, and then simulate hours worth of computing (or 
at least the task-switches) can be *very* useful. 

IMHO, making it easy to test new scheduling algorithms is a very neat way of 
attracting new kernel/scheduler hackers (as well as testing all sorts of crazy 
algorithms).

Just my $0.02

-- 
     henrik

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]