Re: [Linux-hls-devel] Some questions about the schedulers...

[John R. <re...@cs...>]

Hi Luca,

It may take me a little while to page this in...

> 1) is HLS_MAXIMUM_PRIORITY a valid RR priority? Looking at the current
> implementation of hls_sched_rr:RR_B_CallbackMsg(), it seems that it is
> (there is a test "if (m->pri < 1 || m->Pri > HLS_MAXIMUM_PRIORITY)"...),
> but if I try to use it, I obtain an oops... Probably I did something
> wrong when porting from Windows to Linux? John, if you still have your
> old Windows source, can you have a look?

I'll take a look in the morning.

> 2) in hls_sched_res, the Revoke Callback is implemented as an ASSERT(0).
> Since in the past I broke the whole debug & assert mechanism, this
> assertion was never triggered, but now that I fixed the debugging stuff
> hourglass is triggering the assertion. What's the reason for having
> ASSERT(0) in the Revoke Callback? Can I assume that it is just because
> it still has to be implemented? In this case, I'll change it in an
> hls_printk("FIXME: Implement the revoke callback...").

Argh, this is one of the dirty little secrets of HLS... some schedulers
work only on uniprocessor machines and some only work when connected
directly to a root scheduler.  Probably both restrictions are true of the
RES scheduler.

I think that my reasoning here was that a RES scheduler can't make
guarantees effectively if the CPU gets revoked from it.  Also, a
reservation anywhere in the hierarchy should be able to be moved to a RES
scheduler near the root without affecting overall allocation.  Or
something like that.  Basically, you only use a reservation scheduler when
you need a fairly hard guarantee, so in this case why would you revoke the
CPU?

John