From: Anton Blanchard <anton@samba.org>
To: Maneesh Soni <smaneesh@in.ibm.com>
Cc: tridge@samba.org, lkml <linux-kernel@vger.kernel.org>,
lse tech <lse-tech@lists.sourceforge.net>
Subject: Re: [Lse-tech] Re: [RFC][PATCH] Scalable FD Management using Read-Copy-Update
Date: Thu, 12 Apr 2001 08:51:18 -0700 [thread overview]
Message-ID: <20010412085118.A26665@va.samba.org> (raw)
In-Reply-To: <20010409201311.D9013@in.ibm.com> <20010411182929.A16665@va.samba.org> <20010412211354.A25905@in.ibm.com>
In-Reply-To: <20010412211354.A25905@in.ibm.com>; from smaneesh@in.ibm.com on Thu, Apr 12, 2001 at 09:13:54PM +0530
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
next prev parent reply other threads:[~2001-04-12 15:54 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 [this message]
2001-04-17 10:49 ` Scalable FD Management Maneesh Soni
2001-04-17 14:36 ` 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=20010412085118.A26665@va.samba.org \
--to=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=smaneesh@in.ibm.com \
--cc=tridge@samba.org \
/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