Re: Hurd Advocacy?
> > L4 also provides for user-space scheduling, besides the standard
> > in-kernel scheduler. Putting the scheduling policy out of the
> > kernel opens up new interesting possibilities, like, perhaps
> > real-time threads and better support for SMP systems as well.
>
> Yeah, but it is not at all obvious to me how to do this, and happily, the
> Hurd itself doesn't need real time. We will use some of the scheduling
> interfaces in the device driver, in particular preemption control for
> interrupt handlers.
Ack.
The obvious application is when you run multiple OS servers on top of
L4 in parallel, each one with its own scheduler. Say, we could run a
BSD server with a BSD-like user-level scheduler, a Linux server with
its own scheduler, and multiple Hurd servers, which could be allocated
CPU time slices from a Hurd schedule-server. All user-level
schedulers will of course have to be derived from a higher-level
scheduler or the in-kernel scheduler of L4 itself.
I'm just speculating here, so please don't take this to the letter:
In Hurd/L4, some servers can't have the same scheduling requirements.
As you've pointed out, a device driver task which contains drivers
that poll interfaces would run at a different priority than a "normal"
translator or user-level task. In monolithic kernels, drivers are
often being scheduled implicitely through ISR calls (when hardware
interrupts the CPU or a timer expires). This means that the drivers
run at highest priority, bypassing the regular scheduler. In Hurd/L4,
with separate driver tasks, we must ensure that interrupts are being
delivered _and_ _quickly_ accepted by interrupt threads in the driver
task(s). Those threads may (and probably will) need to run at higher
priority than the rest of the (Hurd) gang. The interrupt-threads could
run on a higher-priority L4 queue, but that would be dangerous,
because L4 ensures strict order scheduling [if a higher-priority
thread livelocks, all threads running at normal priority will never
again have a chance to run]. So we'll have to do our own scheduling,
so as not to lock up the system.
Anyway, this is getting technical, and we should probably discuss
this on l4-hurd@ rather than in this advocacy thread.
> As about SMP support, we certainly want to do that, but
> it will not be possible to do it at a local level like memory. Neal gave
> the heuristic argument to me at Oslo. He said, to paraphrase him, that all
> memory pages are equal (ie it doesn't matter which page you get), but all
> time slices are not. In particular, it does indeed matter if you get the
> next, let's say, one million time slices, or if you get only one and then
> have to wait a bit until everybody else got a chance to run, and that one
> million times. Also, time is consumed and then useless to anybody else,
> while access to memory can be revoked temporarily without too much problems
> (there is still the issue of caching etc, but it's controllable).
Yes, I think I understand what Neal means here. Although very
different, similar issues arise in FreeBSD 5.x KSEs. But I admit that
I don't yet fully understand what's going on there.
> The choice of the processor to run on is also not free for the user, because
> that would open the system to DoS attacks. For example, let's say you run
> an important task on processor A. Then N users tasks can cooperate in that
> they all choose to run on processor A.
Ensuring fairness in the use of the available CPUs is a typical scheduling
problem, which would be dealt with by in-kernel or user-level scheduler.
Mach had processor sets to which you could assign threads, and Mach
switched CPUs in the processor set according to its own internal scheduler.
So it's nothing new, it just pops up again in different cloths (or APIs).
> So although the scheduling parameters in L4 are interesting, and will make
> it possible to provide exciting user level features like real time, it is
> still entirely open how this could be done "the Hurd way". ;)
Yes, absolutely. I guess that we will have to experiment with real code,
once we have some drivers to work on. From what we observe, we may then
come up with a more Hurd-ish solution.
Thanks,
-Farid.
--
Farid Hajji. http://www.farid-hajji.net/address.html
Reply to: