Subject: Re: [linux-audio-dev] 2.4.0test5-pre4-lowlat latencies benchmarked, 2.2.16+Ingo's LL patch = strange behaviour
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Wed Jul 26 2000 - 08:33:09 EEST
Hi Andrew,
On Wed, Jul 26, 2000, Andrew Morton wrote:
> Iain Sandoe wrote:
>> I'm hoping that a comment you've made here might throw some light on the
[...]
>> PPC audio types on this list).
> when a CPU is executing kernel code it will run-to-completion. That is,
> the CPu won't run another process until it returns from the current
> system call (or page fault) or until it voluntarily deschedules itself.
Understood...
> The problem is that there are circumstances under which the kernel
> simply has a lot of computing to do. Take the case of:
>
> malloc(100 megs)
> touch the memory
> exit()
>
> when exit() is running in the kernel it has to sit in a loop freeing up
> 25,000 pages of memory. Each one takes quite a lot of work and the net
> effect is that the exit() system call takes 25 milliseconds.
also understood...
> So it's not related to the duration of interrupt routines. The longest
> ISR duration on a well-tuned Linux box is 60 microseconds.
I wish I could say that the LinuxPPC is as well-tuned right now... 450 to
750 us for some actions right now :-(
> The only way around this problem is:
>
> 1: Make the kernel preemptible. This could be done fairly easy on a
> uniprocessor box with some trickery, but I don't think anyone's done it.
This is an idea I saw in Jun Sun's paper (it seems quite amazingly elegant
to me)... has an engineering simplicity... and makes use of existing
resources from the SMP kernel...
> 2: Put in selected preemption points where the kernel knows it's being a
> CPU hog and so voluntarily reschedules periodically.
understood why this is not popular (i.e. the antithesis of the engineering
simplicity above)...
> 3: Add more CPUs. And keep adding, and keep adding.... This isn't a
> very good solution.
I'm not a fan of the "let's put more resources in" solutions either...
=====
My point was (re. Linuxppc) that, in the case of the 'green lines', we seem
to have some action (kernel or otherwise) that is precipitated by
pre-emption of the SCHED_FIFO task. This (AFAIK) can only happen as a
result of an IRQ - given that we have not voluntarily given up the CPU (by
doing a sys call etc. ) - which is my interpretation of what the green line
is supposed to represent.
If that interpretation is wrong (don't claim to be an expert :-) then I'm
chasing a wild goose... and hence the question about "instrumentation"...
The question is "what?" is happening... I don't think we have TIMEPEGS yet
on PPC so it might be hard to find out the user of the time...
FWIW I already have a wrapper round do_page_fault() (although this occurs
with ints enabled so the actual time is not logged at present). I could
(reasonably easily) check that particular situation... I already know it's
not page_hash-ing (which does occur with ints disabled).
Out of the office today (on paid work :) so ponder this in spare moments..
Iain.
This archive was generated by hypermail 2b28 : Wed Jul 26 2000 - 09:10:03 EEST