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