linux-hls-devel — All the discussions about HLS happen here...

Re: [Linux-hls-devel] Processes freezing up

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

Hi Tony,

first of all, welcome!!!
  
> I've included the dmesg output below.
>  
> HLS MP initializing (HLS_DBG_PRINT_LEVEL = 1).
> [-1961706252], 833 : sched 'ROOT' registered in slot 0
> [-1885129302], 833 : sched 'JOIN' registered in slot 1
> [-1808565821], 833 : sched 'TH' registered in slot 2
> [-1734729187], 833 : sched 'RR' registered in slot 3
> [-1660892643], 833 : sched 'PS' registered in slot 4
> [-1587056079], 833 : sched 'RES' registered in slot 5
> already PRIVATE_DATA != NULL???
> already PRIVATE_DATA != NULL???
> hls_ctl: Moving to res1
>     ...and setting the parameters!
Everything is ok, until here...

> bug: kernel timer added twice at e24c1689.
This is very bad, and could be the root of the problem :(
How much time does it pass between the program start and this message?
Does the application freeze immediately after this message?

> HLSUnblockThreadHook --- WAI = 2    [512]
> HLSUnblockThreadHook --- WAI = 2    [512]
> HLS ERROR: Task 687 has rt_priority = 100 and state = 1
> HLSUnblockThreadHook --- WAI = 5    [512]
> HLSUnblockThreadHook --- WAI = 5    [512]
> HLS ERROR: Task 687 has rt_priority = 100 and state = 1
> HLS ERROR: Task 687 has rt_priority = 100 and state = 1
[...]
Ok, HLS is having serious problems here... :( It seems that a hook is
interrupting another hook, and that some tasks are not currently
descheduled. I must have a better look...
Can you write down a simple example that triggers this bug? That would
help a lot.

> And also, when my process freezes, I'm unable to kill it, even with kill
> -9 <pid>!
Uhmm... This could be due to the fact that HLS sets its priority to a
very low value. Removing the HLS module should permit to kill the task
(if it does not crash the system...).

> Any help would be appreciated, and let me know if I can enable any more
> debugging to give more information.
The only idea that I have right now is that the problem can be related
to a bad interaction with the preemption patch... Are you using it? If
yes, can you try to remove the kernel preemption patch (and eventually
the low-latency patch) and try to reproduce the problem?

			Thanks,
				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:
Al Garden Center Peraga sta per prendere forma un evento straordinario: il labirinto delle pannocchie. Un’occasione unica per divertirsi in un’oasi di pace...
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1616&d=3-9

[Linux-hls-devel] Processes freezing up

[Tony L. <tl...@au...>]

Hi Luca/John,
=20
I'm a work colleague of Paul Koufalas and have been looking with him at
running our application with the HLS scheduler.
=20
I've encountered an issue where processes seem to freeze up after
running for any amount of time. Sometimes it's my application and I've
also noticed it happen with top.
=20
I've included the dmesg output below.
=20
HLS MP initializing (HLS_DBG_PRINT_LEVEL =3D 1).
[-1961706252], 833 : sched 'ROOT' registered in slot 0
[-1885129302], 833 : sched 'JOIN' registered in slot 1
[-1808565821], 833 : sched 'TH' registered in slot 2
[-1734729187], 833 : sched 'RR' registered in slot 3
[-1660892643], 833 : sched 'PS' registered in slot 4
[-1587056079], 833 : sched 'RES' registered in slot 5
already PRIVATE_DATA !=3D NULL???
already PRIVATE_DATA !=3D NULL???
hls_ctl: Moving to res1
    ...and setting the parameters!
bug: kernel timer added twice at e24c1689.
HLSUnblockThreadHook --- WAI =3D 2    [512]
HLSUnblockThreadHook --- WAI =3D 2    [512]
HLS ERROR: Task 687 has rt_priority =3D 100 and state =3D 1
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLS ERROR: Task 687 has rt_priority =3D 100 and state =3D 1
HLS ERROR: Task 687 has rt_priority =3D 100 and state =3D 1
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLS ERROR: Task 687 has rt_priority =3D 100 and state =3D 1
HLS ERROR!!! Task state changed during the hook??? 0 !=3D 1!!!
Correcting...
HLS ERROR: Task 512 has rt_priority =3D 100 and state =3D 1
HLS ERROR: Task 512 has rt_priority =3D 100 and state =3D 0
HLS ERROR: Task 687 has rt_priority =3D 100 and state =3D 1
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLS ERROR: Task 687 has rt_priority =3D 100 and state =3D 1
HLS ERROR: Task 507 has rt_priority =3D 100 and state =3D 1
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLSUnblockThreadHook --- WAI =3D 5    [512]
HLS ERROR: Task 507 has rt_priority =3D 100 and state =3D 1
=20
Here are the processes that are in error:
=20
root       687   685  0 18:37 ?        00:00:00 in.telnetd: dm3
root       507     1  0 18:37 ?        00:00:00 syslogd -m 0
root       512     1  0 18:37 ?        00:00:00 klogd -x
=20
On a previous run, I was seeing error messages with the init process, ie
..
=20
Sep  3 17:58:16 wally kernel: HLS ERROR: Task 1 has rt_priority =3D 100
and state =3D 1
Sep  3 17:58:16 wally kernel: HLS ERROR: Task 1 has rt_priority =3D 100
and state =3D 1
Sep  3 17:58:16 wally kernel: HLSUnblockThreadHook --- WAI =3D 5    =
[511]
Sep  3 17:58:16 wally kernel: HLSUnblockThreadHook --- WAI =3D 5    =
[511]
Sep  3 17:58:16 wally kernel: HLS ERROR: Task 1 has rt_priority =3D 100
and state =3D 1
Sep  3 17:58:16 wally kernel: HLS ERROR!!! Task state changed during the
hook??? 0 !=3D 1!!! Correcting...
=20
And also, when my process freezes, I'm unable to kill it, even with kill
-9 <pid>!
=20
I don't know if it's related, but I've also seen the following messages
in the syslog:
=20
Sep  3 18:50:17 wally kernel: hls_ctl: Moving to res1
Sep  3 18:50:17 wally kernel:     ...and setting the parameters!
Sep  3 18:50:22 wally kernel: bug: kernel timer added twice at e24c1689.
=20
Any help would be appreciated, and let me know if I can enable any more
debugging to give more information.
=20
Thanks and regards,
Tony

[Linux-hls-devel] About SCHED_FIFO and SCHED_OTHER...

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

Hi guys,

I was thinking about what to do when a user program tries to change an
HLS task to SCHED_FIFO or SCHED_OTHER (see one of my latest mails to the
list, and my last commit, for a more complete description of the
problem).
The current code can act in two ways (configurable through an ifdef):
1) do nothing ---> The task remains an HLS task
2) transform the task in a regular linux task

Both the two previous possibilities have problems... Hence, I had a
third idea:
we can have a "rt scheduler" (similar to the "default scheduler" that we
already have), and move a task to such scheduler when the policy is
changed to SCHED_FIFO or SCHED_RR... In the "default hierarchy" that is
automatically built by the HLS module, rr1 will be the rt scheduler.

What do you think? Can this be a good idea?

If yes, I'll implement this solution in the next days.

			Thanks,
				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 già scoperto le nuove collezioni 2003? Ti aspettiamo su Miotti.it!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1449&d=3-9

RE: [Linux-hls-devel] HLS errors appearing with cpu reservations

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

Hi John,
 
> It's true that without help from the scheduler, Hourglass cannot ensure
> that a thread period is synched up with its reservation.
> 
> However, this 550 ms anomaly sounds like it's too large to be explained by
> a phase difference,
Yes you are right... 550ms is too much. This seems to be some kind of
transient phenomenon happening on the startup of a periodic task (I do
not see it if the hourglass task is not periodic). I am wondering if
hourglass periodic tasks do some kind of synchronization on startup...
Ok, I'll have a look at the code.
 
> Paul, is the HLS code in the Hourglass pre-release working for you?
I just sent it to him 1 minute ago. Anyway, it is working fine for me.
If you can wait some days before the release, I have some cleanups to
do, and I have a patch for PPC support (!!!). (yes, I tested it on my
ibook ;).

> > Integrating HLS with high-resolution-timers is on my todo list, but it
> > requires some important changes to the code... It will take some time
> > (although I know how to integrate the two things, because I already did
> > something similar for another project).
> 
> Cool.  Was this the CBS scheduler you guys put into Linux?
Yes; you can compare
http://feanor.sssup.it/cgi-bin/cvsweb.cgi/cbs/src/timers.c?rev=1.8&content-type=text/x-cvsweb-markup
and
http://feanor.sssup.it/cgi-bin/cvsweb.cgi/cbs/src/hrt.c?rev=1.3&content-type=text/x-cvsweb-markup
to see the modifications that are needed.

Unfortunately, the latest version of the high-resolution-timers patch
still does not export some symbols that are needed for using hr timers
from a module, and an additional patch is needed.

				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:
L'interpretazione dei doni di orti, frutteti, prati e giardini nel nostro Ristoro Sunflower.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1478&d=29-8

RE: [Linux-hls-devel] HLS errors appearing with cpu reservations

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

> > The 10s trace looks as I expected apart from a 500ms portion near the
> > start. Task 1 gets the CPU for its first period and then nothing until
> > 550ms; thereafter it gets 10ms every 50ms.
> I think this can be due to the fact that the reservation period and the
> task period are not synchronized (if I understand well, hourglass has no
> way to ensure the fact that the two periods are in phase... Or am I
> wrong? John, please correct me...).

It's true that without help from the scheduler, Hourglass cannot ensure
that a thread period is synched up with its reservation.

However, this 550 ms anomaly sounds like it's too large to be explained by
a phase difference, so I have no idea what's happening.

I changed offices this summer and my HLS test box is still sitting in a
corner turned off.  I'll get it running in the near future and try to
reproduce this.

Paul, is the HLS code in the Hourglass pre-release working for you?  If
so, I should roll out Hourglass 0.6.  There were a few other issues I was
trying to iron out relating to CPU speed detection on laptops and other
difficult machines but now that was so long ago I've forgotten the
issues...

> Integrating HLS with high-resolution-timers is on my todo list, but it
> requires some important changes to the code... It will take some time
> (although I know how to integrate the two things, because I already did
> something similar for another project).

Cool.  Was this the CBS scheduler you guys put into Linux?

John

RE: [Linux-hls-devel] HLS errors appearing with cpu reservations

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

Hi Paul,

On Thu, 2003-08-28 at 21:41, Paul Koufalas wrote:
> Hi Luca,
> 
> I ran schedtest after changing SCALE to 1196350 (1.2GHz mobile P-III) in
> i386-rdtsc.h
Thanks for the testing!
 
> This is on the 2.4.18-gensched kernel with (still) RML's variable-hz
> (HZ=1000), preemption and lockbreak patches.
> 
> (I've yet to repeat tests without the latter RML preepmtion and
> lock-breaking patches.)
I think at this point it is not necessary to repeat the test, becausing
according to the logs that you sent everything is working perfectly ;-)

All the logs show the typical (30, 100) rsv behaviour (in this case,
something similar to a sequence of "Distance: 70000    Size: 30000").

Hence, I'd say that everything is almost ok. The only thing that scares
me is:
> It didn't happen this time around but the first time I tried testing I
> found that schedtest  hung at the 2nd trial. A second telnet session to
> the box was okay. But I couldn't seem to kill schedtest, either. I had
> to reboot and then the 3 trials ran okay.
If this happens again, can you try to see if the dmesg output shows
anything unusual?

			Thanks,
				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 bisogno di un nuovo decoder per guardare le partite della tua squadra del cuore? Trovalo qui!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=765&d=29-8

RE: [Linux-hls-devel] HLS errors appearing with cpu reservations

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

Hi Paul,

On Thu, 2003-08-28 at 21:24, Paul Koufalas wrote:
> Hi Luca,
> 
> Yes, the patch to bottom.c seems to have fixed the problem with
> hourglass.
Good to know. Thanks for reporting the problem and testing the fix.
 
> Typing 
> 
> hourglass -n 2 -t 1 -rh 10ms 50ms -w PERIODIC 10ms 50ms
> 
> gave the following output:
> 
> ...
> thread 1 will have hard res of amount 10000 and period 50000
> thread 1 will run workload PERIODIC
> thread 1 will have amount 10000
> thread 1 will have period 50000
[...]
> time slots in ms: thread start end duration gap:
> tracerec: 1 1.012524 1.987656 0.975132 601243.730409
> tracerec: 1 1.999265 2.988340 0.989075 0.011609
> tracerec: 1 2.999037 3.989064 0.990026 0.010697
> tracerec: 1 3.999727 4.989773 0.990046 0.010663
> ... 
> 
> The 10s trace looks as I expected apart from a 500ms portion near the
> start. Task 1 gets the CPU for its first period and then nothing until
> 550ms; thereafter it gets 10ms every 50ms.
I think this can be due to the fact that the reservation period and the
task period are not synchronized (if I understand well, hourglass has no
way to ensure the fact that the two periods are in phase... Or am I
wrong? John, please correct me...).

> (BTW, the missed deadlines count drops to only 1 if 11ms is reserved for
> task 1 rather than 10ms exactly; John pointed the need to do this in an
> hourglass conference paper I have.)
In fact... Scheduling a (10, 50) task with a (10, 50) reservation is a
little bit risky, because there always could be up to 1jiffy (1ms if
HZ=1000) allocation error. A solution to the problem could be to
increase HZ; the "right way" to address the issue is to use
high-resolution-timers.
Integrating HLS with high-resolution-timers is on my todo list, but it
requires some important changes to the code... It will take some time
(although I know how to integrate the two things, because I already did
something similar for another project).

> However, dmesg still shows us some HLS issues:
[...]
> already PRIVATE_DATA != NULL???
> already PRIVATE_DATA != NULL???
Until here, everything is ok, I think

> HLS Error: 902 has private_data = NULL???
This is expected, as I did not remove the printk()
> ../hls/hls_hooks.c:56: failed HLS assertion: "(State ==
> TASK_UNINTERRUPTIBLE) || (State == TASK_INTERRUPTIBLE)".
> ../hls/hls_hooks.c:56: failed HLS assertion: "(State ==
> TASK_UNINTERRUPTIBLE) || (State == TASK_INTERRUPTIBLE)".
> HLS ERROR: not panicing, but continuing...
> HLS ERROR: not panicing, but continuing...
I do not know about this, but it can be due to my latest change (and is
probably harmless). I'll double-check this evening.
 
> When I get a chance I'll rebuild the 2.4.18 kernel without RML's
> preemption and lock breaking patches and see if the HLS error msgs go
> away.
That would be great.
Anyway, at this poing I would say that things are working ok even with
preemption and lock breaking.

			Thanks,
				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:
Le nuove iniziative del Garden Center Peraga: i Tour Day Peraga per andare alla scoperta del Canavese e il Labirinto delle Pannocchie per perdersi in un’oasi di pace, a contatto con la natura.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1615&d=29-8

RE: [Linux-hls-devel] HLS errors appearing with cpu reservations

[Paul K. <pko...@au...>]

Hi Luca,

Yes, the patch to bottom.c seems to have fixed the problem with
hourglass.

I'm using 2.4.18 with HLS gensched patch, and (still for now) RML's
variable-hz, preemption and lock-break patches.

Typing=20

hourglass -n 2 -t 1 -rh 10ms 50ms -w PERIODIC 10ms 50ms

gave the following output:

...
thread 1 will have hard res of amount 10000 and period 50000
thread 1 will run workload PERIODIC
thread 1 will have amount 10000
thread 1 will have period 50000
5.722046 MB allocated for trace records
Hourglass 0.5 : 2 threads; 10.000000 seconds; 1194.408907 MHz processor
max gap is 2388 cycles
this test will last for 10.000000 seconds

numthreads: 2
work done by thrd 0 : 125491982
work done by thrd 1 : 25940366
thread 1: missed 170 deadlines, hit 20
there were 10009 out of 300000 trace records; 3.336333 % used.
in cycles, trace start 718129657440, end 730083432498, duration
11953775058
trace duration 10.008109 seconds
thread 0 recorded 7.990135 seconds
thread 1 recorded 1.890859 seconds
total thread time 9.880994 seconds

time slots in ms: thread start end duration gap:
tracerec: 1 1.012524 1.987656 0.975132 601243.730409
tracerec: 1 1.999265 2.988340 0.989075 0.011609
tracerec: 1 2.999037 3.989064 0.990026 0.010697
tracerec: 1 3.999727 4.989773 0.990046 0.010663
...=20

The 10s trace looks as I expected apart from a 500ms portion near the
start. Task 1 gets the CPU for its first period and then nothing until
550ms; thereafter it gets 10ms every 50ms.

(BTW, the missed deadlines count drops to only 1 if 11ms is reserved for
task 1 rather than 10ms exactly; John pointed the need to do this in an
hourglass conference paper I have.)=20

However, dmesg still shows us some HLS issues:

HLS MP initializing (HLS_DBG_PRINT_LEVEL =3D 1).
[738959619], 801 : sched 'ROOT' registered in slot 0
[812802016], 801 : sched 'JOIN' registered in slot 1
[886628438], 801 : sched 'TH' registered in slot 2
[957733126], 801 : sched 'RR' registered in slot 3
[1028835251], 801 : sched 'PS' registered in slot 4
[1101303379], 801 : sched 'RES' registered in slot 5
already PRIVATE_DATA !=3D NULL???
already PRIVATE_DATA !=3D NULL???
HLS Error: 902 has private_data =3D NULL???
../hls/hls_hooks.c:56: failed HLS assertion: "(State =3D=3D
TASK_UNINTERRUPTIBLE) || (State =3D=3D TASK_INTERRUPTIBLE)".
../hls/hls_hooks.c:56: failed HLS assertion: "(State =3D=3D
TASK_UNINTERRUPTIBLE) || (State =3D=3D TASK_INTERRUPTIBLE)".
HLS ERROR: not panicing, but continuing...
HLS ERROR: not panicing, but continuing...
hls_ctl: Moving to res1
    ...and setting the parameters!

When I get a chance I'll rebuild the 2.4.18 kernel without RML's
preemption and lock breaking patches and see if the HLS error msgs go
away.

Regards,

Paul Koufalas
Senior Communications Engineer
AUSPACE Limited
Level 1 Innovation House
Technology Park MAWSON LAKES SA 5095
AUSTRALIA
T +61 8 8260 8236
F +61 8 8260 8226
M +61 404 837 122
www.auspace.com.au
This email is for the intended addressee only. If you have received this
e-mail in error, you are requested to contact the sender and delete the
e-mail. Nothing in this email shall bind Auspace Limited in any contract
or obligation.



-----Original Message-----
From: Luca Abeni [mailto:luc...@em...]=20
Sent: Friday, August 29, 2003 2:38 PM
To: lin...@li...
Subject: Re: [Linux-hls-devel] HLS errors appearing with cpu
reservations


Hi Paul,

I reproduced the bug, and I think I fixed it.

This was the problem: hourglass does first a sched_setscheduler(p,
SCHED_FIFO, ...), and then does another sched_setscheduler() to schedule
it with the res scheduler. But the first setsched() transformed the task
in a regular linux task, and the second one complained about this fact
without changing the task to HLS...

Now, it should work. Have a look at the patch on the cvs commit mailing
list (it will appear in the anonymous cvs in 1 or 2 days).

This brings up a question: what should we do when a sched_setscheduler()
is performed on an HLS task changing the policy to SCHED_FIFO, SCHED_RR,
or SCHED_OTHER? Two possibilities:
1) do nothing (the task remains an HLS task)
2) transform the task in a regular linux task. This is a little bit
conterintuive, because regular linux task are scheduled in background
respect to HLS tasks...

Other possibilities would require to know the scheduler hierarchy in
advance...

Ideas and suggestions are welcome.

			Thanks,
				Luca
--=20
________________________________________________________________________
_____
 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:
Non hai ancora aperto Conto Arancio? Allora clicca qui.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3D667&d=3D28-8


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Linux-hls-devel mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-hls-devel

Re: [Linux-hls-devel] HLS errors appearing with cpu reservations

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

Hi Paul,

I reproduced the bug, and I think I fixed it.

This was the problem: hourglass does first a sched_setscheduler(p,
SCHED_FIFO, ...), and then does another sched_setscheduler() to schedule
it with the res scheduler. But the first setsched() transformed the task
in a regular linux task, and the second one complained about this fact
without changing the task to HLS...

Now, it should work. Have a look at the patch on the cvs commit mailing
list (it will appear in the anonymous cvs in 1 or 2 days).

This brings up a question: what should we do when a sched_setscheduler()
is performed on an HLS task changing the policy to SCHED_FIFO, SCHED_RR,
or SCHED_OTHER?
Two possibilities:
1) do nothing (the task remains an HLS task)
2) transform the task in a regular linux task. This is a little bit
conterintuive, because regular linux task are scheduled in background
respect to HLS tasks...

Other possibilities would require to know the scheduler hierarchy in
advance...

Ideas and suggestions are welcome.

			Thanks,
				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:
Non hai ancora aperto Conto Arancio? Allora clicca qui.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=667&d=28-8

[Linux-hls-devel] HLS errors appearing with cpu reservations

[Paul K. <pko...@au...>]

Hi Luca (& John),

I'm perservering with HLS but still having limited success. In addition
to the HLS gensched patch to 2.4.18, I've also applied RML's variable-hz
(HZ=3D1000), preemption and lock breaking patches.

I compiled a monolithic module using=20

make CLI=3D1 INT_SCHED=3D1 CREATE=3D1 MULDIV=3D1 DEBUG=3D1

I'm seeing the following messages in /var/log/messages:

HLS MP initializing (HLS_DBG_PRINT_LEVEL =3D 1).
[-879068745], 1154 : sched 'ROOT' registered in slot 0
[-802493633], 1154 : sched 'JOIN' registered in slot 1
[-725930209], 1154 : sched 'TH' registered in slot 2
[-652093576], 1154 : sched 'RR' registered in slot 3
[-578256736], 1154 : sched 'PS' registered in slot 4
[-504418000], 1154 : sched 'RES' registered in slot 5
ProcFSed rr1 RR root
Creating rr1 of type RR and father root
ProcFSed res1 RES rr1
Creating res1 of type RES and father rr1
ProcFSed rr2 RR rr1
Creating rr2 of type RR and father rr1
ProcFSed ps1 PS rr1
Creating ps1 of type PS and father rr1
already PRIVATE_DATA !=3D NULL???
already PRIVATE_DATA !=3D NULL???
HLS Error: 1168 has private_data =3D NULL???
HLS Error: 1167 has private_data =3D NULL???
HLS Error: 1166 has private_data =3D NULL???

The last three relate to some experiments with John's hourglass program.
I'm trying to verify that CPU reservations are working with the kernel
I'm using and rather than using my real-time application I thought I'd
try hourglass.

I'm not much of a programmer but I looked at the hourglass code and
wrote a make_res_hls() function for HLS CPU reservations (see below). I
then modified hourglass.h, work.c to call this when WITH_HLS was
defined.

#include <hourglass.h>
#include "/usr/src/hls/include/sched.h"
#include "/usr/src/hls/include/hls.h"
#include "/usr/src/hls/include/rsv.h"
#include <signal.h>

#define MAX_SETS 100

struct sched_param *sp =3D NULL;
struct hls_param *hlsp =3D NULL;
struct CPU_RESERVATION *rsv =3D NULL;
 =20
void make_res_hls (us_time amount,=20
		   us_time period,
		   int which,
		   pthread_t thrd)
{
  int res;

  if (!sp) {
    sp =3D (struct sched_param *) xmalloc (MAX_SETS *=20
					 sizeof (struct sched_param));
    memset (sp, 0, MAX_SETS * sizeof (struct sched_param));
    hlsp =3D (struct hls_param *) xmalloc (MAX_SETS * sizeof (struct
hls_param));
    memset (hlsp, 0, MAX_SETS * sizeof (struct hls_param));
    rsv =3D (struct CPU_RESERVATION *) xmalloc=20
      (MAX_SETS * sizeof (struct CPU_RESERVATION));
    memset (rsv, 0, MAX_SETS * sizeof (struct CPU_RESERVATION));     =20
  }
  /*
  printf("--- CPU reservation for thread %d (%ld)\n",which,thrd);
  printf("amount =3D %lf, period =3D %lf, which =3D %d
(%d)\n",amount,period,which,
	 thrd);
  printf("sp[which] =3D 0x%X\n",&sp[which]);
  printf("hlsp[which] =3D 0x%X\n",&hlsp[which]);
  printf("rsv[which] =3D 0x%X\n",&rsv[which]);
  */

  printf ("thread %d res: amount =3D %d ms\n",=20
	  which, ((int)amount)/1000);
  printf ("thread %d res: period =3D %d ms\n",
	  which, ((int)period)/1000);

  sp[which].sched_size =3D sizeof(struct hls_param);
  sp[which].sched_p =3D &hlsp[which];
  hlsp[which].signature =3D HLS_SIGNATURE;
  hlsp[which].command =3D 0;
  hlsp[which].scheduler =3D "res1";
  hlsp[which].sched_data_size =3D sizeof (struct CPU_RESERVATION);
  hlsp[which].sched_data =3D &rsv[which];
  rsv[which].Amount =3D (int)amount*10;
  rsv[which].Period =3D (int)period*10;
  rsv[which].Soft =3D 0;

  res =3D pthread_setschedparam(thrd, SCHED_HLS, &sp[which]);
 =20
  if (res < 0) {
    printf ("oops: could not create CPU reservation for thread %d
(%ld)\n",=20
	    which, thrd);
    exit (-1);
  }

}=20

I'm not seeing what I expected to see in the hourglass output when one
of the tasks has a cpu reservation: instead all hourglass threads get
about the same work done; they get ~40ms of CPU time each in a round
robin fashion.

Best regards,

Paul Koufalas
Senior Communications Engineer
AUSPACE Limited
Level 1 Innovation House
Technology Park MAWSON LAKES SA 5095
AUSTRALIA
T +61 8 8260 8236
F +61 8 8260 8226
M +61 404 837 122
www.auspace.com.au
This email is for the intended addressee only. If you have received this
e-mail in error, you are requested to contact the sender and delete the
e-mail. Nothing in this email shall bind Auspace Limited in any contract
or obligation.

Re: [Linux-hls-devel] Fixed bug in /proc/HLS/tasks

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

On Wed, 2003-08-27 at 12:47, John Regehr wrote:
> > reservation, hence I can confirm that times are expressed in 100ns
> > units. (this will probably change in the future, but for the moment you
> > can work with 100ns).
> 
> Would microseconds be more appropriate?  They are pretty intuitive for me.
> When stuffing microseconds into an unsigned 32-bit int you can represent
> time intervals up to a little over an hour.
I fully agree, here.

But I'd like to do the change "in the Right Way (TM)", modifying the
semantic of HLSSetTimer(). But I want to study the effects of such
change, first...

Anyway, this is the next item on my todo list.

				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:
Con KLM puoi risparmiare fino a 20 Euro sul tuo biglietto aereo prenotando on line per Usa, Europa e il resto del mondo
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1259&d=28-8

Re: [Linux-hls-devel] Fixed bug in /proc/HLS/tasks

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

> reservation, hence I can confirm that times are expressed in 100ns
> units. (this will probably change in the future, but for the moment you
> can work with 100ns).

Would microseconds be more appropriate?  They are pretty intuitive for me.
When stuffing microseconds into an unsigned 32-bit int you can represent
time intervals up to a little over an hour.  This is probably long enough
for most things people do with kernel schedulers.  If someone is
scheduling events for more than an hour in the future, they're probably
using cron, not HLS!

John

[Linux-hls-devel] Fixed bug in /proc/HLS/tasks

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

Hi all,

I just fixed a bug that prevented /proc/HLS/tasks from being updated
when a task was moved between HLS schedulers.
The fix will appear in the anonymous cvs in 1 day or 2. For the moment,
you can see it in the linux-hls-cvs mailing list:
http://lists.sourceforge.net/lists/listinfo/linux-hls-cvs
(this particular commit is
http://sourceforge.net/mailarchive/forum.php?thread_id=3030715&forum_id=18244)

Now, everything seems to work as expected.

Paul, I checked schedtest, and the RSV scheduler seems to work ok... The
reservation created by the program correctly behaves as a (30ms, 70ms)
reservation, hence I can confirm that times are expressed in 100ns
units. (this will probably change in the future, but for the moment you
can work with 100ns).

				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:
L’estate si avvicina.. dai un’occhiata al nostro vasto assortimento di occhiali da sole i più trendy sono su.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1445&d=27-8

[Linux-hls-devel] RE: Changing HZ from 100 to 500 or 1000

[Paul K. <pko...@au...>]

Ciao Luca,

Thanks for the HZ test. I tried it on two linux boxes, one with =
HZ=3D1000
running 2.4.18-gensched and the other running RHL 7.3.

I typed:

./jittertest -r

It looks like RML's HZ patch works ok with HZ=3D1000 (as he maintains); =
in
Res.txt the third column has numbers close to 1.=20

On the RHL 7.3 box, Res.txt has numbers around 10-18.

Regards,=20

Paul Koufalas
Senior Communications Engineer
AUSPACE Limited
Level 1 Innovation House
Technology Park MAWSON LAKES SA 5095
AUSTRALIA
T +61 8 8260 8236
F +61 8 8260 8226
M +61 404 837 122
www.auspace.com.au
This email is for the intended addressee only. If you have received this
e-mail in error, you are requested to contact the sender and delete the
e-mail. Nothing in this email shall bind Auspace Limited in any contract
or obligation.



-----Original Message-----
From: Luca Abeni [mailto:luc...@em...]=20
Sent: Wednesday, August 27, 2003 7:20 PM
To: lin...@li...
Cc: Paul Koufalas
Subject: Re: Changing HZ from 100 to 500 or 1000


Hi Paul,

> We tried this 2 ways:
>
> 1. Using Robert Love's patch:=20
> variable-hz-rml-2_4_20-pre10-ac2-1_patch.text
> applied to a 2.4.18 kernel (no rejects occurred)
>=20
> 2. Hard coding HZ in include/asm/param.h
Both the two ways should work ok, but the first one is "more correct",
because is does not screw some statistics in the procfs.

> Neither seemed to make much of a difference.
>=20
> Is there a way to check if the change is in effect? Ie,=20
> measure/estimate HZ from /proc or elsewhere?
I think the best way is to measure it from user space (for example, by
setting an itimer with period 1ms, and checking how oftern the timer
signal is triggered). I attach a program that does something similar. It
sets an itimer at 1000us, but on a standard kernel the real period will
be 10ms (see the third column in Res.txt). With HZ=3D1000, the third
column should contain values around 1.0

> On the other hand, if we didn't setup up res1 parameters Amount and=20
> Period using the correct units, we would expect to be dropping/missing

> frames in our application.
I suspect this can be the reason... A full dmesg output would be useful.

> Were you able to confirm that 1 unit =3D 100ns?
I still have to check to be 100% sure, but I think it is 100ns. I'll
check this evening.

				Luca

P.S.: I sent the previous mail to the wrong list... This
(lin...@li...) is the correct one. Sorry for
the confusion.
--=20
________________________________________________________________________
_____
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:
Il computer dei tuoi sogni lo crei tu a partire da 899 Euro. Clicca e
componi il tuo PC. Clicca qui:
http://adv.email.it/cgi-bin/foclick.cgi?mid=3D1732&d=3D27-8

[Linux-hls-devel] [Fwd: [Linux-hls-cvs] Re: /proc/HLS/tasks listing schedulers correctly?]

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

I sent this message to the wrong list...

-----Forwarded Message-----

> From: Luca Abeni <luc...@em...>
> To: Paul Koufalas <pko...@au...>
> Cc: lin...@li...
> Subject: [Linux-hls-cvs] Re: /proc/HLS/tasks listing schedulers correctly?
> Date: 27 Aug 2003 10:35:15 +0100
> 
> Hi Paul,
> 
> > Luca, we ran schedtest and examined /proc/HLS/tasks while it was
> > running: it said that schedtest was using rr2, not res1 as the 
> > scheduler.
> I checked, and it does not seem to be a typo. I think there is something
> wrong in hls_setsched()... Thanks for finding and reporting the bug.
> 
> I will need to reproduce the problem, and to debug it; I'll do it this
> evening. I think I know where the bug is, but I'll need some testing;
> maybe something like this patch can fix it:
> Index: linux/hls_ctl.c
> ===================================================================
> RCS file: /cvsroot/linux-hls/hls/linux/hls_ctl.c,v
> retrieving revision 1.6
> diff -u -r1.6 hls_ctl.c
> --- linux/hls_ctl.c     25 Feb 2003 09:18:55 -0000      1.6
> +++ linux/hls_ctl.c     27 Aug 2003 08:24:48 -0000
> @@ -97,10 +97,12 @@
>   
>    HLS_ASSERT (th1->vp->State == VP_Waiting);
>    th1->vp->TopSched = new_sched;
> -  
> + 
>    status = th1->vp->TopSched->CB->B_RegisterVP(new_sched, th_inst,
> th1->vp);
>    HLS_ASSERT(status == HLS_SUCCESS);
> -  
> + 
> +  th->Parent = new_sched;
> +
>    HLSDbgPrint(3, ("(infr) registered\n"));
>  
>    /* This cannot be done until the sched param are set...
> 
> 
> (WARNING: This is a completely untested patch)
> If I am right, the bug should not affect the scheduling (only /proc
> information are broken).
> 
> It would be useful to know if schedtest is behaving correctly for you:
> can you send to the list the complete output of schedtest, together with
> the contents of /proc/HLS/* ?
> 
> 			Thanks,
> 				Luca
> -- 
> _____________________________________________________________________________
> Copy this in your signature, if you think it is important:
>                                N O    W A R ! ! !

-- 
_____________________________________________________________________________
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:
Migliaia di prodotti al prezzo che decidi tu. Fai subito la tua offerta!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1650&d=27-8

[Linux-hls-devel] Re: Changing HZ from 100 to 500 or 1000

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

Hi Paul,

> We tried this 2 ways:
>
> 1. Using Robert Love's patch:
> variable-hz-rml-2_4_20-pre10-ac2-1_patch.text
> applied to a 2.4.18 kernel (no rejects occurred)
> 
> 2. Hard coding HZ in include/asm/param.h
Both the two ways should work ok, but the first one is "more correct",
because is does not screw some statistics in the procfs.

> Neither seemed to make much of a difference.
> 
> Is there a way to check if the change is in effect? Ie,
> measure/estimate HZ from /proc or elsewhere?
I think the best way is to measure it from user space (for example, by
setting an itimer with period 1ms, and checking how oftern the timer
signal is triggered).
I attach a program that does something similar. It sets an itimer at
1000us, but on a standard kernel the real period will be 10ms (see the
third column in Res.txt). With HZ=1000, the third column should contain
values around 1.0

> On the other hand, if we didn't setup up res1 parameters Amount and
> Period using the correct units, we would expect to be dropping/missing
> frames in our application.
I suspect this can be the reason... A full dmesg output would be useful.

> Were you able to confirm that 1 unit = 100ns?
I still have to check to be 100% sure, but I think it is 100ns. I'll
check this evening.

				Luca

P.S.: I sent the previous mail to the wrong list... This
(lin...@li...) is the correct one. Sorry for
the confusion.
-- 
_____________________________________________________________________________
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:
Il computer dei tuoi sogni lo crei tu a partire da 899 Euro. Clicca e componi il tuo PC.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1732&d=27-8

[Linux-hls-devel] Re: Scheduler Hierarchy - HLS

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

Hi Christian, (I am also ccing the hls devel mailing list)

 
> Taking part in a project group at the University of Dortmund (Germany) 
> I am very interested in John's HLS theory.
Good!!! I am very happy to see people interested in HLS.


> I am currently trying to get a hierarchy of schedulers running on my 
> own. The kernel compiled well, but the insertion of some modules failed 
> :
> 
> 	[root@bockermann linux]# insmod hls_sched_res.o
> 	hls_sched_res.o: unresolved symbol __divdi3
[...]

Ok, I assume that you compiled the modular version, and you already
inserted hls_module.o... Can you send me a full compilation log
(including the commands that you used to compile the modules)?
Also, It would be useful to have a
cat /proc/ksyms
before inserting hls_module.o and after inserting it...
As a quick workaround, you can compile the schedulers inside
hls_module.o, by typing
make CLI=1 INT_SCHED=1 KERNEL_DIR=/home/luca/src/linux-rt
or you can avoid using __divdi3 by adding MULDIV=1 to the compilation
command.

I suggest you to get the cvs version of hls from
cvs.linux-hls.sf.net/cvsroot/linux-hls (cvs module name: hls)
- See the sf project page (http://www.sf.net/projects/linux-hls) for
more details - and to have a look at the "scripts" directory.
 
> 	[root@bockermann linux]# insmod hls_sched_th.o
> 	hls_sched_th.o: unresolved symbol HLSSetPri
> 	hls_sched_th.o: unresolved symbol _hls_assertion_failed
> 	hls_sched_th.o: unresolved symbol HLS_DBG_PRINT_LEVEL
> 	hls_sched_th.o: unresolved symbol HLSScheduleThread
> 	hls_sched_th.o: unresolved symbol ThreadStr
> 	hls_sched_th.o: unresolved symbol HLSProc
> 	hls_sched_th.o: unresolved symbol HLSFindThread
> 	hls_sched_th.o:
> 	Hint: You are trying to load a module without a GPL compatible license
> 	      and it has unresolved symbols.  Contact the module supplier for
> 	      assistance, only they can help you.
BTW, you should never insert hls_sched_th.o: it is a special scheduler
(it is a pseudo-scheduler modelling a thread). Hence, it is always
linked into hls_module.o (HLS cannot exist without hls_sched_th.o).

> Did I do anything wrong ? Is there more documentation about the way to 
> specify the parameters of the schedulers ?
Well, you are hitting the biggest problem of the hls-on-linux
implementation: the lack of documentation. All the existing
documentation is at
http://linux-hls.sourceforge.net/compile.html
and
http://linux-hls.sourceforge.net/use.html

Anyway, I am here to answer all the questions ;-)
Let me know if using MULDIV=1 solved the problem...

> Is there any way to set a 
> certain task to a certain scheduler from outside ? Like "echo PID 
> PARENT_SCHED > /proc/HLS/tasks" ?
The only way to assign a task to a scheduler is to use the
sched_setscheduler() system call, as shown in tests/schedtest.c. Of
course, you can specify the pid of the task that you prefer, hence you
can set schedulers "from outside".

The proc interface can be used to construct scheduler hierarchies, as
shown by the create_hierarchy script (in the scripts directory).

I hope this helps to solve your problems...
Tomorrow I will leave for vacations, and I'll be back on August 17.
Hence, I'll be able to answer questions only until this evening.

			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:
Samsonite ti presenta la nuova F'Lite Lite. E una sorpresa!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1756&d=7-8

[Linux-hls-devel] =?iso-8859-1?Q?Test...?=

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

Ok,=0D=0A=0D=0Athis is the usual ``test'' message. Tradition wants that a=
 similar=0D=0Amessage is sent to every newly-created ML... ;)=0D=0A=0D=0A=
                        Luca



--
Prendi GRATIS l'email universale che... risparmia: http://www.email.it/f

Sponsor:
Vuoi una ricetta molto interessante per i tuoi risparmi?
Ti serve la zucca di Conto Arancio.
Clicca qui: http://adv2.email.it/cgi-bin/foclick.cgi?mid=3D666&d=3D12-12