Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

[Mark_H_Johnson]

>* Mark_H_Johnson@xxxxxxxxxxxx <Mark_H_Johnson@xxxxxxxxxxxx> wrote:
>
>> I don't expect turning the debugging off will make that much of a
>> difference but I can try it tomorrow. [...]
>
>so basically this is your setup:
>- prio 99: all IRQ threads and ksoftirqd threads
Plus events/0 and /1 at RT FIFO 99.

> - prio 30: 'CPU loop' from latencytest, generating ~80% CPU load
That is the nominal case. It may be a little higher in some of the
runs (where the audio loop is consistently "fast") but never over
100% of a CPU unless you ask for a periodic sync [which I don't].

> - SCHED_OTHER: workload generators
Two primary tasks as SCHED_OTHER:
 - cpu_burn (nice w/ default, according to manpage its 10)
 - whatever workload generator is active (not nice)
I tend to also run with one or more "data collectors" which are
shell scripts that I run like this...
  chrt -f 1 ./get_ltrace.sh 250
They do sleeps of various durations (seconds) before looking at
/proc for data.

>and the metric is "delays in the prio 30 CPU loop", correct?
The % within 100 usec is always in the prio 30 CPU loop. The max
latency I sometimes mention is for that CPU loop as well
(80% of nominal audio duration). For the max latency, I try to
mention if its the delta or total time. (but sometimes forget)

The elapsed time is for the workload generator / RT application,
whichever gets done first. That is because the script starts both
(latencytest in background) and there is a killall after the
workload generator gets finished (which latencytest traps & dumps
its data to the output files). latencytest will automatically
stop after about 250000 samples - hence the upper limit of about
6 minutes for the test time.

--Mark H Johnson
  <mailto:Mark_H_Johnson@xxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/