From: Dipankar Sarma <dipankar@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: viro@parcelfarce.linux.theplanet.co.uk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] files: scalable fd management (V4)
Date: Wed, 15 Jun 2005 17:48:42 +0530 [thread overview]
Message-ID: <20050615121841.GB4845@in.ibm.com> (raw)
In-Reply-To: <20050614130338.70e99074.akpm@osdl.org>
Hello Andrew,
On Tue, Jun 14, 2005 at 01:03:38PM -0700, Andrew Morton wrote:
> Dipankar Sarma <dipankar@in.ibm.com> wrote:
> > tiobench on a 4-way ppc64 system :
> > (lockfree)
> > Test 2.6.10-vanilla Stdev 2.6.10-fd Stdev
> > -------------------------------------------------------------
> > Seqread 1428 32.47 1475.0 29.11
>
> We don't seem to have gained anything?
I repeated the measurements on ramfs (as opposed to ext2 on ramdisk in
the earlier measurement) and I got more consistent results from tiobench :
4(8) way xeon P4
-----------------
(lock-free)
Test 2.6.12-rc5 Stdev 2.6.12-rc5-fd Stdev
-------------------------------------------------------------
Seqread 1282 18.59 1343.6 26.37
Randread 1517 7 2415 34.27
Seqwrite 702.2 5.27 709.46 5.9
Randwrite 846.86 15.15 919.68 21.4
4-way ppc64
------------
(lock-free)
Test 2.6.12-rc5 Stdev 2.6.12-rc5-fd Stdev
-------------------------------------------------------------
Seqread 1549 91.16 1569.6 47.2
Randread 1473.6 25.11 1585.4 69.99
Seqwrite 1096.8 20.03 1136 29.61
Randwrite 1189.6 4.04 1275.2 32.96
Also running Tridge's thread_perf test on ppc64 :
2.6.12-rc5-vanilla
--------------------
Running test 'readwrite' with 4 tasks
Threads 0.20 +/- 0.02 seconds
Processes 0.16 +/- 0.01 seconds
2.6.12-rc5-fd
--------------------
Running test 'readwrite' with 4 tasks
Threads 0.18 +/- 0.04 seconds
Processes 0.16 +/- 0.01 seconds
The benefits are huge (upto ~60%) in some cases on x86 primarily
due to the atomic operations during acquisition of ->file_lock
and cache line bouncing in fast path. ppc64 benefits are modest
due to LL/SC based locking, but still statistically significant.
Thanks
Dipankar
prev parent reply other threads:[~2005-06-15 12:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-14 14:26 Dipankar Sarma
2005-06-14 14:27 ` [PATCH 0/6] files: fix rcu initializers Dipankar Sarma
2005-06-14 14:28 ` [PATCH 0/6] files: rcuref APIs Dipankar Sarma
2005-06-14 14:29 ` [PATCH 3/6] files: break up files struct Dipankar Sarma
2005-06-14 14:30 ` [PATCH 4/6] files: files struct with RCU Dipankar Sarma
2005-06-14 14:31 ` [PATCH 5/6] files: lock-free fd look-up Dipankar Sarma
2005-06-14 14:32 ` [PATCH 6/6] files: files locking doc Dipankar Sarma
2005-06-14 14:33 ` [PATCH 0/6] files: rcuref APIs Dipankar Sarma
2005-06-14 14:33 ` [PATCH 0/6] files: fix rcu initializers Dipankar Sarma
2005-06-14 20:03 ` [PATCH 0/6] files: scalable fd management (V4) Andrew Morton
2005-06-14 20:12 ` Dipankar Sarma
2005-06-15 12:18 ` Dipankar Sarma [this message]
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=20050615121841.GB4845@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®