Thread: [Linux-hls-devel] Some questions about the schedulers...
Status: Pre-Alpha
Brought to you by:
lucabe
Menu
▾
▴
linux-hls-devel
|
From: Luca A. <luc...@em...> - 2003-11-01 11:43:02
|
Hi all,
I am going to commit some changes that I did to implement the "rt
scheduler" (similar to the default scheduler) discussed in my previous
mail and to clean up the sources a little bit.
While working on this modifications, I found some strange things in the
code, hence I have some questions for 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?
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...").
Ok, that's all for now... I hope to commit my changes in the next days.
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:
Partecipa anche tu al progetto ShopMon: la Rete che fa bene
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1953&d=1-11
|
|
From: John R. <re...@cs...> - 2003-11-03 02:46:00
|
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
|
|
From: Luca A. <luc...@em...> - 2003-11-03 11:08:10
|
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
|
Thanks for helping keep SourceForge clean.
X