Re: [linux-audio-dev] interesting 2.3.4* kernel statistic

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

Subject: Re: [linux-audio-dev] interesting 2.3.4* kernel statistic
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke helmi  23 2000 - 05:24:59 EST


On Wed, 23 Feb 2000, David Olofson wrote:
> On Tue, 22 Feb 2000, Benno Senoner wrote:
> > I am a little confused by the numbers:
> > With the lowlatency patches we achieve <2-3ms latencies ALWAYS,
> > even when closing files etc.
> > Latencytest ran on my P133 while accessing the disk heavily , stress proc ,
> > and copying the entrire content of two CDs from TWO CDROM drives
> > simultaneously, and a close() call is issued zillions of time during my tests.
>
> This was on a "standard" 2.3.4x kernel, as I understand it (after
> actually reading the posts this time ;-) - not a lowlatency patched
> kernel.

Yes, I know !

>
> > Therefore I don't understand how/if the lockmetering can be applied to do any
> > inferency on how small latencies we can get out of our realtime apps.
>
> A lock only stalls threads that hit them while they're locked by
> other threads... That is, you might avoid getting that big latencies
> because your RT thread never forces the kernel to grab those locks.
> For example, do you need the do_close lock to just access an open
> device? The idea with all these locks in the newer kernels is to
> avoid having a global lock (or even worse, simply disable IRQs on all
> CPUs) while touching the sensitive structs.
>

I think since my testapps I do not open and close files
within the RT main loop, (I only read/write to filedescriptores), we do not
collide with the do_close lock. So we get good results.

This is what Andrea Arcangeli wrote on linux-kernel:

-------
On Wed, 23 Feb 2000, Benno Senoner wrote:
>You will spend several msecs in this loop ruining latencies completely.
>Is there a way to reschedule in a safe way during the freeing of inodes ?

What I did in 2.3.x fixes the problem correctly. I take the not busy
inodes in a separate LRU thus I can reach them in O(1).

Andrea
-------

That means that that during freeing inodes you don't have to reschedule
explicitly since he is only grabbing the non busy nodes.

very promising !
:-)

Benno.


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST