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

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

Hi Paul,

 
> To answer one question it looks like 5 seconds pass before the timer bug
> message appears.
> 
> 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
Ok, thanks! Unfortunately, I did not understand what is going on yet,
but I am working on this...
 
> I don't know if it's relevant but we use the RTC to generate 1 ms (1
> kHz) interrupts to our process.
This should not be a problem.

> I assume that the 1 kHz kernel timer is
> generated by a different timer (the PIC/APIC?)
Yes, it is generated by the PIT.

> We tried to specify a CPU reservation of 5ms out of 6.625ms. Before
> handballing to Tony I previously tested a "simulation" using hourglass
> (v0.6) to check on interrupt latency and deadline misses.
> 
> Typing: 
> 
> hourglass -n 1 -t 0 -rh 5ms 6.625ms -w LAT
> while simultaneously running top with update period 0.01 gave latencies
> of around 1.3ms
> 
> hourglass -n 1 -t 0 -rh 5ms 6.625ms -w LAT -i RTC
> while simultaneously running top with update period 0.01 gave latencies
> of around 0.3ms
>  
> hourglass -n 5 -t 0 -rh 5ms 6.625ms -w PERIODIC 4ms 6.625ms -t 1 -p
> RTHIGH -w PERIODIC 1ms 10ms 
> showed that task 0 met all its deadlines but 1 (missed 1 at the
> beginning, a synchronisation/startup problem still?)
I'll try to have a look and to investigate these latencies.
A thing that I can say for sure is that a period of 6.625 can give some
problems, since it is not a multiple of the system tick (I expect some
additional latencies due to this, but I don't think it is the reason for
the problem you are seeing).

> [Aside: from this I take it that CPU reservations are stronger than
> SCHED_RR/SCHED_FIFO?
In the default hierarchy that is built when the HLS module is loaded,
yes. There is a RR scheduler (rr1), and the res1 scheduler is scheduled
on rr1 with priority 20. All the "regular tasks" are scheduled on
another RR scheduler (rr2), which is scheduled on rr1 with priority 10.
Hence, res tasks are scheduled in foreground respect to all the other
tasks.
Of course, you can change a task to rr1 (with priority > 20) to schedule
1 in foreground respect to res tasks...

> With the latest talk about linux tasks vs HLS
> tasks, what is the relationship between HLS round-robin and linux's
> SCHED_OTHER, SCHED_FIFO and SCHED_RR?
Currently, all linux tasks are scheduled in background respect to HLS
tasks (a non-HLS task is scheduled only when no HLS tasks are ready).
Hence, doing sched_setsched(SCHED_RR) can be dangerous, because it
results to do the opposite of what the user expects... This is what I am
trying to fix.

> Do SCHED_OTHER tasks -> HLS
> round-robin? What about SCHED_RR/SCHED_FIFO tasks?
This is exactly what we have to decide right now... The implemented
solution (SCHED_OTHER, SCHED_RR, SCHED_FIFO --> background respect to
HLS) is not good.

> Is that what you're
> grappling with at the moment, thinking about a HLS rt scheduler?
Yes... You can for example set "rt scheduler = rr1" (for the standard
hierarchy), so that changing a task to SCHED_FIFO or SCHED_RR will
really increase its priority.
 
> Based on the third simulation, I would've thought our application would
> be okay. However it continues to show missed deadline problems. It could
> be we need to revisit reservation requirements, but I'm also keen to
> understand interrupt latency issues and scheduling issues.
Does your application do some setsched(SCHED_FIFO) (or SCHED_RR)? Does
it create a high I/O load?

I am continuing to study the problem reported yesterday (unfortunately,
I cannot reproduce it), and I'll let you know as soon as I discover
something...

				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 capite un cavolo di borsa? Investite nella zucca.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=665&d=4-9