public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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