From: Maneesh Soni <smaneesh@in.ibm.com>
To: Anton Blanchard <anton@samba.org>
Cc: Paul.McKenney@us.ibm.com, dipankar@sequent.com,
lkml <linux-kernel@vger.kernel.org>,
lse tech <lse-tech@lists.sourceforge.net>
Subject: Re: Scalable FD Management ....
Date: Tue, 17 Apr 2001 16:19:16 +0530 [thread overview]
Message-ID: <20010417161916.A11419@in.ibm.com> (raw)
In-Reply-To: <20010409201311.D9013@in.ibm.com> <20010411182929.A16665@va.samba.org> <20010412211354.A25905@in.ibm.com> <20010412085118.A26665@va.samba.org>
In-Reply-To: <20010412085118.A26665@va.samba.org>; from anton@samba.org on Thu, Apr 12, 2001 at 08:51:18AM -0700
On Thu, Apr 12, 2001 at 08:51:18AM -0700, Anton Blanchard wrote:
>
> Hi,
>
> > Base (2.4.2) -
> > 100 Average Throughput = 39.628 MB/sec
> > 200 Average Throughput = 22.792 MB/sec
> >
> > Base + files_struct patch -
> > 100 Average Throughput = 39.874 MB/sec
> > 200 Average Throughput = 23.174 MB/sec
> >
> > I found this value quite less than the one present in the README distributed
> > with dbench tarball. I think the numbers in the README were for a similar
> > machine but with 2.2.9 kernel.
>
> If you guestimate that each dbench client uses about 20M of RAM then dbench
> 100 has no chance of remaining in memory. Once you hit disk then spinlock
> optimisations are all in the noise :) Smaller runs (< 30) should see
> it stay in memory.
>
> Also if you turn of kupdated (so old buffers are not flushed out just
> because they are old) and make the VM more agressive about filling
> memory with dirty buffers then you will not hit the disk and then
> hopefully the optimisations will be more obvious.
>
> killall -STOP kupdated
> echo "90 64 64 256 500 3000 95 0 0" > /proc/sys/vm/bdflush
>
> Remember to killall -CONT kupdated when you are finished :)
>
> > I am copying this to Andrew also, if he can also help. Also if you have some
> > dbench numbers from 2.4.x kernel, please let me have a look into those also.
>
> The single CPU 333MHz POWER 3 I was playing with got 100MB/s when not
> touching disk.
>
> Anton
> -
Hi Anton,
I ran the dbench test as per your suggesstions. Now I get similar throughput
numbers as yours.
But still the throughput improvement is not there for my patch. the reason, I
think, is that I didnot get too many hits to fget() routine. It will be helpful
if you can tell how you got fget() chewing up more than its fair share of CPU
time.
For 30 clients:
Base(2.4.2) - Average Throughput = 235.139 MB/S
Base + Files_struct patch - Average Throughput = 235.751 MB/S
I also did profiling while running these tests, using kernprof. The fget hits
are as below
Base(2.4.2) 304
Base + Files_struct patch 189
Though while doing kernprofile'ing my sample size is quite big (the top ranker
in profiling is "default_idle" with 28471 hits). The fget's hit count is quite
low compared to "default_idle".
As you can also see, the files_struct patch is able to reduce the number of hits
to fget by around 37%
I also saw the dbench.c code. It does creates no. of child processes but with
fork() and not through __clone().
I think the fget() will affect the performance in the scenarios where the
childs are created using clone() with CLONE_FILES flag set. That is when many
child processes share parent's files_struct and everybody tries to acquire the
same files->file_lock. And in those scenarios we should see considerable
performance improvement by using the files_struct patch as in the case of "chat"benchmark.
Regards,
Maneesh
--
Maneesh Soni <smaneesh@in.ibm.com>
http://lse.sourceforge.net/locking/rclock.html
IBM Linux Technology Center,
IBM Software Lab, Bangalore, India
next prev parent reply other threads:[~2001-04-17 10:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-09 14:43 [RFC][PATCH] Scalable FD Management using Read-Copy-Update Maneesh Soni
2001-04-12 1:29 ` Anton Blanchard
2001-04-12 15:43 ` [Lse-tech] " Maneesh Soni
2001-04-12 15:51 ` Anton Blanchard
2001-04-17 10:49 ` Maneesh Soni [this message]
2001-04-17 14:36 ` Scalable FD Management Andi Kleen
2001-04-12 18:23 ` [Lse-tech] Re: [RFC][PATCH] Scalable FD Management using Read-Copy-Update John Hawkes
2001-04-16 16:16 ` Mark Hahn
2001-04-17 9:28 ` Dipankar Sarma
2001-04-17 16:59 ` Mark Hahn
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=20010417161916.A11419@in.ibm.com \
--to=smaneesh@in.ibm.com \
--cc=Paul.McKenney@us.ibm.com \
--cc=anton@samba.org \
--cc=dipankar@sequent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
/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