On Mon, 13 Mar 2000, Linus Torvalds wrote:
> Ingo Molnar wrote:
>> > hm, current->spinlock_depth should work pretty well i believe, no? That
>> > one is SMP-safe as well. It doesnt have any global cacheline problems
>> > either.
>>
>> Agreed, but what is the point of it? Now every spinlock has to look up
>> current. The nice spinlock code that used to be 2 instructions (or 1
>> for the unlock case) suddenly became 5 or more. No, thank you.
>> Especially as I don't believe it buys you anything on SMP.
>
Notice that for getting low-latencies in specific RT apps we don't need the
"perfect case" .
take the audio playing example
the SCHED_FIFO
process simply
do
while(1)
{
.. do computations
write() to soundcard's fd
}
even if some spin lock is held, the write() above is independent
from other subsystems, therefore with your old low-latency approach
in your 2.2.10 patches ( conditionally rescheduling in the paths which take too
long to execute, like buffercache etc.) I get my desired results of <3ms
latencies.
Would Linus accept a patch in 2.4 based on your old approach ?
>yep, i agree that it's overkill for SMP. 99% of RT applications are UP, so
>the global depth-counter should be enough.
>
> Ingo
I would't claim that all RT apps have to be UP,
in the realtime audio field you need low latencies AND huge amounts of
processing power, therefore it would be VERY desirable to get these
3ms latencies on SMP boxes too, since it would allow us to parallelize
most of DSP algorithms , doubling the effective computational power in case
of two CPUs.
Ingo, I know that your 2.2.x patches do not perform well on SMP hardware,
is the global depth counter a potentail solution to this ?
And the old approach had ZERO impact on performance compared
to a stock kernel, (measured with both lmbench and bonnie),
since the reschedules occured mainly buffercache functions, and only
when a SCHED_FIFO process was run.
Linus, can we make a compromise including a patch into 2.4 which uses
the Ingo's old , simple approach (but with additions which make it work well
on SMP too) , since it provides latencies good enough for pratical work.
A 2.4 kernel without low latency will be a big show stopper for high-performance
multimedia applications, and we can't afford that the
desktop Joe Average user has to download patches, and recompile kernels
only to enjoy smooth multimedia. (which should be ovious with these modern
300 MIPS monsters we have on the desktop)
PS: I may have missed some part of the discussion,
can someone please enlighten me if you agreed to a praticable solution.
(A solution which could be accepted into the 2.4 kernel)
I agree with Linux that a clean "good" solution is better than potentially
broken "perfect" solution.
Benno.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:21 EST