Subject: Re: [linux-audio-dev] interesting 2.3.4* kernel statistic
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: ti helmi 22 2000 - 17:09:05 EST
Benno Senoner wrote:
>
> On Tue, 22 Feb 2000, Roger Larsson wrote:
> and a close() call is issued zillions of time during my tests.
> > >
> > > 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) Tested on an unpatched 2.2.x
> > b) Tested on current 2.3.x. Basically unpatched too since I have not
> > seen
> > Ingo M. announce his 2.3 patch yet. Some things are fixed during
> > development.
> > I.e with the version tested your worst case will be at least 34 ms.
> > Since several locks might be taken during one kernel operation.
> >
> > /RogerL
>
> Did you test lockmetering on a 2.2.10-lowlatencyN6B kernel ?
No,
But he who tested and got 34 ms. What did he test on.
kernel? patches? memory (very important)?
I checked my kernel list and here it is:
lk> From: Manfred Spraul <manfreds_AT_colorfullife.com> Sat 13:53
lk> Subject: spin lock contention: lru_list lock
lk>
lk> I tried sgi's lockmeter with 2.3.46, and during a simple
lk>
lk> make -j4 dep
lk>
lk> I get extremely long hold times for the lru_list lock:
lk>
lk> sync_buffers(): up to 14 milliseconds, average 12 milliseconds.
[called
lk> 10 times per second.]
lk> __invalidate_buffers(): up to 8 milliseconds, average 7
milliseconds.[
lk> called ~4.5 times/sec]
lk>
lk>
lk> I assume that everything is cached:
lk> * 192 MB memory.
lk> * /proc/meminfo: Cached 122 MB
lk> * slabinfo: dentry_cache: 17705 entries, inode cache 15174 entries,
lk> buffer heads: 108189 entries.
lk>
lk> Is it possible to optimize sync_buffers()/__invalidate_buffers()
lk> further? I assume that with 1 GB memory, the hold times could become
a
lk> problem for a huge fileserver.
lk>
lk> --
lk> Manfred
lk> P.S.: some good news: except do_close [up to 34 milliseconds], noone
lk> else owns a spinlock for more than 3 milliseconds.
lk>
Kernel: 2.3.46
Patch: there is no known lowlatency patch yet.
Memory: 192 MB a lot (in cach 122 MB, ...)
=> You can not compare the numbers (unless you run a 2.3.x kernel)!
>
> I don't pretend to trigger the worst case with my system stressing benchmark,
> but if the worst case would be 34ms why I am staying below the 3ms mark ?
>
> Benno.
/RogerL
-- Home page: http://www.norran.net/nra02596/
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST