[linux-audio-dev] Re: new preemptive kernel-patch from Montavista available

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Re: new preemptive kernel-patch from Montavista available
From: george anzinger (george_AT_mvista.com)
Date: Mon Nov 27 2000 - 23:42:22 EET


Andrew Morton wrote:
>
> Benno Senoner wrote:
> >
> > Hi,
> > Andrew Morton informed me that Montavista has released a new
> > preemptive kernel, which seems to achieve 2msec latencies when
> > running latencytest. (I haven't tested it yet).
> > I'm attaching Nigel's message below.
>
> OK, I've had a quick poke through it.
>
> It's definitely a work-in-progress. The decision to not
> do any form of context switch (preemptive or cooperative) when the
> "big kernel lock" is held means that it's fairly easy to get large
> scheduling dropouts - I saw one of 70 milliseconds quite early
> into testing.
>
> Also the performance is down a bit - a bonnie++ benchmark run
> goes from 6min13 to 6min31. A kernel compile from 6min11 to 6min45.
>
So here is a question for the group. How much does performance suffer
if we run a UP with an SMP kernel? I suspect this is about what we
should expect when all is said and done. Why? Well we need to enter
mutex areas with an atomic action, the same as a spinlock. The
difference is that we will be doing it on both UP and SMP systems. The
SMP system should see no change to a net improvement (less time spinning
-> more work).

> The patch is fairly x86-specific and doesn't address SMP.
>
> But it's way too early to judge these things. I think MontaVista
> are waiting until the filesystem guys completely remove the big lock in
> the 2.5 stream.

THAT would be very NICE. In the mean time I am looking at a way to turn
it into a mutex. First we need to boot... Ideas abound..
>
> Plus if I were them I wouldn't invest the effort of doing the SMP and
> non-x86 work unless they got some sort of buy-in beforehand from
> Linus (good luck...).

Or someone wants to pay. Actually I think we have some interest in the
PPC area.
>
> I don't think MontaVista are targetting this as a 2.4 kernel feature,
> but I've Cc:'ed Nigel and George so they can speak for themselves.

Gosh, we had hoped that the kernel would already be at 2.5. Heck no,
don't even think of this as a 2.4 feature. Given the right in$entive we
might support a 2.4 patch. We started out targeting this for 2.5/6.

So, here is a puzzle for you. One of the areas we need to deal with is
read/write lock regions. Currently, we disable preemption for these
areas. What we would like to do is use pi_mutex (priority inherit
mutex). Does any one have any good ideas as to how to enter/leave such
a mutex as a reader? Remember, if the holder is to be priority boosted,
we need to know who he is. Do we limit the number of readers? Even so,
it looks like the entry code is too costly. Ideas?

George


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Nov 28 2000 - 00:35:21 EET