Subject: Re: [linux-audio-dev] 2.4.0test5-pre4-lowlat latenciesbenchmarked, 2.2.16+Ingo's LL patch = strange behaviour
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Wed Jul 26 2000 - 13:17:21 EEST
Iain Sandoe wrote:
>
> 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.
It can be an interrupt that triggers a bh handler.
Interrupt handling is often split in two parts.
a) the real interrupt routine, does what it has to do with interrupt
off,
queues a back handler to run when leaving interrupt routine.
b) back handler starts after interrupt service but before returning to
user process.
Example:
you get a interrupt that indicates HD is done with last job. Then you do
not
actually need to start next in the interrupt routine, only take care of
the
condition that causes the interrupt. Return from interrupt. On doing
that
it notices that there is more requests against the disk. And starts
next...
(it was some time since I looked into this subject - I think a slightly
different approach is used nowadays - tasklets)
/RogerL
-- Home page: http://www.norran.net/nra02596/
This archive was generated by hypermail 2b28 : Wed Jul 26 2000 - 13:57:21 EEST