public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dipankar Sarma <dipankar@in.ibm.com>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: [PATCH 0/6] files: scalable fd management (V4)
Date: Tue, 14 Jun 2005 19:56:12 +0530	[thread overview]
Message-ID: <20050614142612.GA4557@in.ibm.com> (raw)

This is an updated version of patchset published earlier
at - http://marc.theaimsgroup.com/?l=linux-kernel&m=111747394710704&w=2

Since then I have done the following additional testing :

1. SMP/UP kernels with and without CONFIG_PREEMPT on x86 and ppc64.
   running various tests like ltp, dbench, tiobench, reaim. 

2. Testing with a testcase that creates > 1024 fds and exercises
   the vmalloc allocation and freeing path.

3. More 24+ hour runs on both x86 and ppc64

4. Touch testing with X running on a desktop.

5. Testing with __ARCH_HAS_CMPXCHG undefined. I booted and ran some
   basic tests with this on a ppc64 SMP box in order to exercise
   the hashed locking.

Additional performance #s :
---------------------------

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
Randread        1469.2          17.27   1599.6          35.95
Seqwrite        262.06          9.31    246.8           30.94
Randwrite       548.38          12.49   521.4           61.98

With LL/SC based locks, cache line bouncing effect of file_lock
is not as pronounced, but it still makes a difference 
with seq and random reads.

Andrew, would it be possible to give this some testing time
in -mm ? If so, please let me know what would be an appropriate
time for that and I will send patches against -mm.

Thanks
Dipankar

             reply	other threads:[~2005-06-14 14:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-14 14:26 Dipankar Sarma [this message]
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

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=20050614142612.GA4557@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