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

[Luca A. <luc...@em...>]

Hi John,

> > 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.
Ok, thanks.

[...]
> 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.
Uhmm... This is a very interesting theoretical problem... Some time ago,
I was working on hierarchical reservations (a res scheduler attached to
a "father" res scheduler), and I argued that from the rt guarantee point
of view a hierarchy of reservations can be modeled as a single
reservation (computing the proper values for such rsv)... But I was
unable to proved this fact (there are weird cases in which the father
reservation is active but the child is depleted, or the two rsv are not
synchronized...).

Anyway, I think that having the possibility to construct hierarchies
with res scheduler in other places than the root would increase the
flexibility of HLS.

> Basically, you only use a reservation scheduler when
> you need a fairly hard guarantee, so in this case why would you revoke the
> CPU?
Well, this is what is happening right now:
1) hourglass main process calls sched_setscheduler() assigning the
highest rt priority to itself
2) as a result, the hls module moves the hourglass process to rr1, with
the highest rt priority (this is the effect of my latest changes ;-)
3) the hourglass "worker threads" are moved to the res scheduler
(because I selected -rh 10ms 50ms, or something like that).
4) When the main hourglass process is woken up, the assertion is
triggered...
[BTW... You know, I don't like hard guarantees and hrt too much ;)]

When the assertion was disabled (because of my debugging configuration
mess), the Revoke callback was doing nothing, and everything was working
fine (I think this is because the hourglass main process does not really
consume much time...). Hence, I suppose that leaving the callback empty
(or printing a warning) would be ok for the moment... 

I am thinking about implementing the callback in a proper way. My
current idea is that we should try to avoid putting too much policy in
the HLS module (urgh... I am using the policy vs mechanism argument!!!
Shame on me... ;). In other words, I'd be for "you get what you
deserve": if a user attaches the RES scheduler to another scheduler, he
must know what he is doing... And if he knows, maybe revoking the CPU
from the RES scheduler is the right thing to do...

I think a proper Revoke callback should:
1) account the executed time to the proper res task
2) stop the depletion timer
Of course, a proper Grant callback should be implemented too...
Is this ok? John, what do you think about this?

			Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Hai una fotocamera digitale e vuoi stampare le tue immagini
su vera carta fotografica professionale?
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1533&d=3-11