From: Robert Love <rml@tech9.net>
To: Dave Jones <davej@suse.de>
Cc: Andrew Morton <akpm@zip.com.au>,
Linus Torvalds <torvalds@transmeta.com>,
viro@math.psu.edu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5: push BKL out of llseek
Date: 29 Jan 2002 21:37:57 -0500 [thread overview]
Message-ID: <1012358278.817.83.camel@phantasy> (raw)
In-Reply-To: <20020130032138.H16379@suse.de>
In-Reply-To: <Pine.LNX.4.33.0201291602510.1747-100000@penguin.transmeta.com>, <Pine.LNX.4.33.0201291602510.1747-100000@penguin.transmeta.com> <1012351309.813.56.camel@phantasy> <3C574BD1.E5343312@zip.com.au> <1012357211.817.67.camel@phantasy> <20020130032138.H16379@suse.de>
On Tue, 2002-01-29 at 21:21, Dave Jones wrote:
> did you benchmark with anything other than dbench ?
No, and I really don't want to hear how dbench is a terrible benchmark.
I didn't craft the patch around dbench and I think, here at least,
dbench is an OK benchmark. I ran it numerous times over multiple client
loads.
I think its clear there won't be a negative impact, because:
- acquiring the inode semaphore isn't any heavier (in the acquire
case) than the BKL
- the lock contention on each inode semaphore is relatively
zero
- besides just scaling badly with the using a global lock against
all inodes, we use the BKL which in such workloads is already
highly contested.
That said, I did do some lock profiling and latency tests. Contention
was near-zero, but I only did 2-way testing. Under the preemptible
kernel, while running dbench, scheduling latency improved 8.9%.
Robert Love
next prev parent reply other threads:[~2002-01-30 2:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-30 0:00 [PATCH] 2.5: push BKL out of llseek Robert Love
2002-01-30 0:09 ` Linus Torvalds
2002-01-30 0:41 ` Robert Love
2002-01-30 0:52 ` Linus Torvalds
2002-01-30 2:24 ` Robert Love
2002-01-30 1:26 ` Andrew Morton
2002-01-30 2:16 ` Linus Torvalds
2002-01-30 2:20 ` Robert Love
2002-01-30 2:20 ` Andrew Morton
2002-01-30 2:21 ` Dave Jones
2002-01-30 2:37 ` Robert Love [this message]
2002-01-30 2:50 ` Nigel Gamble
2002-01-30 3:19 ` Andrew Morton
2002-01-30 9:34 ` Nigel Gamble
2002-01-30 10:36 ` Russell King
2002-01-30 4:54 ` Alexander Viro
2002-01-30 8:00 ` Trond Myklebust
2002-01-30 13:39 ` Robert Love
2002-01-30 4:50 ` Anton Blanchard
2002-01-30 5:03 ` Robert Love
-- strict thread matches above, loose matches on Subject: below --
2002-01-30 21:14 Martin Wirth
2002-01-31 15:39 Martin Wirth
2002-01-31 21:06 ` Nigel Gamble
2002-02-01 19:29 John Hawkes
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=1012358278.817.83.camel@phantasy \
--to=rml@tech9.net \
--cc=akpm@zip.com.au \
--cc=davej@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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.