Re: [linux-audio-dev] State of kernel?

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

Subject: Re: [linux-audio-dev] State of kernel?
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Fri Oct 13 2000 - 21:46:48 EEST


Benno Senoner wrote:
>
> On Tue, 10 Oct 2000, Roger Larsson wrote:
> >
> > Conclusion: finer grained locking will improve both SMP performance for
> > computers with lots of processors and make low latency kernels possible.
> > Note: you need to add an extra check for if scheduling is required when
> > you leave a lock - some do not want this overhead and the kernel will
> > probably end up with several compilation options.
> >
> > SMP / UP
> > standard / preemtive
> >
> > with the combinations of SMP-standard, UP-preemtive, UP-standard being
> > the most common.
>
> Roger, does SMP-preemptive make sense ?
> what if one wants low latencies on a SMP box ?
> Will SMP-standard be enough ?
> I mean: assume you have 2 CPUs:
> there are 3 threads running, two of them holding a lock, and
> a third SCHED_FIFO thread (the famous audio thread with 1msec fragments), which
> wants to be scheduled, but is unable to do so, because both CPUs must "wait"
> until the next lock release.
> Am I saying nonsense ?

One CPU is executing inside a lock protected region.
The other one is spinning on the lock.
The third process wants to be scheduled but gets scheduled on the second
CPU.
=> The first will not notice...

=> You have to check for rescheduling in the spin lock...
Hmm... That could be done... It is in the slow path anyway...
But it has one problem - you have to have a count for the number of
locks
you are holding already, you can't reschedule when holding locks.
(Ingo does this make sense?)

=> It can probably be done but question is if it is worth it. It will
have
interesting problems to solve...

>
> Can you explain the behaviour ?
>
> Plus I would be interesed in an analogous case ( dual CPU box) where
> there are two threads holding a lonck and two audio threads running (assume
> we have two soundcards in our box and each audio thread outputs the data on a
> separate soundcard with small buffersizes)
>

please elaborate, is there two or four threads?
 
> thanks for infos,
>
> Benno.
>
> >
> >
> > /RogerL

--
Home page:
  http://www.norran.net/nra02596/


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

This archive was generated by hypermail 2b28 : Fri Oct 13 2000 - 22:25:37 EEST