From: Andrew Morton <akpm@osdl.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: dwmw2@infradead.org, viro@parcelfarce.linux.theplanet.co.uk,
manfred@colorfullife.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC] kill sleep_on
Date: Sat, 17 Jan 2004 23:36:18 -0800 [thread overview]
Message-ID: <20040117233618.094c9d22.akpm@osdl.org> (raw)
In-Reply-To: <1074409074.1569.12.camel@nidelv.trondhjem.org>
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> På su , 18/01/2004 klokka 01:41, skreiv Andrew Morton:
> > It would be nice to fix up the lock_kernel()s in the NFS client: SMP lock
> > contention is quite high in there.
>
> Chuck did a study of that particular issue some 2-3 years ago, but we've
> addressed all the top problems on his list since then. Do you have any
> new numbers to show us? I ask because I'm not at all convinced that the
> BKL adds significantly to our latencies for the moment (I've been
> looking at those number in the last few days due to the readahead
> problems that have already been reported).
>
> I am, however, quite convinced that we need new statistics on this sort
> of issue. Chuck is therefore working on a set of patches to add an
> "iostat"-like tool to the NFS client. Hopefully that will help settle
> these questions.
>
Well a quick profile of `dbench 4' on a localhost mount on a P4-HT:
c01445fc kmem_cache_alloc 495 6.1875
c0140d28 buffered_rmqueue 514 1.7133
c012a8b4 del_timer_sync 1043 3.7250
c013ea58 generic_file_aio_write_nolock 1316 0.4398
c011fa60 __wake_up 1472 33.4545
c0158a35 .text.lock.read_write 1541 26.1186
c012113f .text.lock.sched 2443 4.1197
c011f3f4 schedule 2782 1.8065
c0109034 default_idle 65504 1259.6923
00000000 total 91786 0.2234
Turning on spinlock inlining:
c0143ec0 kmem_cache_alloc 464 6.1053
c01405c8 buffered_rmqueue 510 1.6346
c012a260 __mod_timer 540 1.7308
c012a4d4 del_timer_sync 949 3.3893
c013e378 generic_file_aio_write_nolock 1340 0.4479
c011fa1c __wake_up 1556 29.9231
c0157054 remote_llseek 1886 6.6408
c011f3a4 schedule 5158 3.3407
c0109034 default_idle 33731 648.6731
00000000 total 59918 0.1457
That's quite a lot of contention on the lock_kernel() in remote_llseek().
The context switch rate is 45000/sec, so schedule() gets a workout.
I do recall seeing quite a lot of BKL contention within NFS itself running
across 100bT on 4-way. That was several months ago - maybe things
improved?
next prev parent reply other threads:[~2004-01-18 7:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-17 18:43 [RFC] kill sleep_on Manfred Spraul
2004-01-17 19:19 ` Arjan van de Ven
2004-01-17 19:28 ` David Woodhouse
2004-01-17 20:10 ` viro
2004-01-17 23:18 ` Trond Myklebust
2004-01-17 23:45 ` David Woodhouse
2004-01-18 6:41 ` Andrew Morton
2004-01-18 6:57 ` Trond Myklebust
2004-01-18 7:05 ` Trond Myklebust
2004-01-18 7:36 ` Andrew Morton [this message]
2004-01-18 7:44 ` Manfred Spraul
2004-01-18 8:03 ` Trond Myklebust
2004-01-18 8:18 ` Manfred Spraul
2004-01-18 17:07 ` Trond Myklebust
2004-01-18 7:54 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040117233618.094c9d22.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.