From: Jakob Oestergaard <jakob@unthought.net>
To: Trond Myklebust <trond.myklebust@fys.uio.no>,
Greg Banks <gnb@melbourne.sgi.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: bdflush/rpciod high CPU utilization, profile does not make sense
Date: Sun, 24 Apr 2005 09:15:24 +0200 [thread overview]
Message-ID: <20050424071523.GV17359@unthought.net> (raw)
In-Reply-To: <20050420135758.GS17359@unthought.net>
On Wed, Apr 20, 2005 at 03:57:58PM +0200, Jakob Oestergaard wrote:
...
> Will try either changing tg3 driver or putting in an e1000 on my NFS
> server - I will let you know about the status on this when I know more.
tg3 or e1000 on the NFS server doesn't make a noticable difference.
Now, I tried booting the 2.6.11 NFS client in uniprocessor mode
(thinking the rpciod threads might be wasting their time contending for
a lock), and that turned out to be interesting.
Performance on SMP NFS client:
File Block Num Seq Read Rand Read Seq Write Rand Write
Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
. 2000 4096 1 47.53 80.0% 5.013 2.79% 22.34 32.2% 6.510 14.9%
. 2000 4096 2 45.29 78.6% 8.068 5.44% 24.53 34.1% 7.042 14.9%
. 2000 4096 4 45.38 78.0% 11.02 7.95% 25.13 35.1% 7.525 18.0%
Performance on UP NFS client:
File Block Num Seq Read Rand Read Seq Write Rand Write
Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
. 2000 4096 1 57.11 54.7% 69.60 24.9% 35.09 14.2% 6.656 19.1%
. 2000 4096 2 60.11 58.8% 70.99 30.8% 33.82 14.1% 7.283 25.1%
. 2000 4096 4 67.89 59.8% 42.10 19.1% 29.86 12.7% 7.850 26.4%
So, by booting the NFS client in uniprocessor mode, I got a 50% write
performance boost, 20% read perforamance boost, and the tests use about
half the CPU time.
Isn't this a little disturbing? :)
--
/ jakob
next prev parent reply other threads:[~2005-04-24 7:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-06 16:01 bdflush/rpciod high CPU utilization, profile does not make sense Jakob Oestergaard
2005-04-06 21:28 ` Trond Myklebust
2005-04-07 15:28 ` Jakob Oestergaard
2005-04-06 23:19 ` Greg Banks
2005-04-07 15:38 ` Jakob Oestergaard
2005-04-07 16:01 ` Greg Banks
2005-04-07 16:17 ` Trond Myklebust
2005-04-09 21:35 ` Jakob Oestergaard
2005-04-09 21:52 ` Trond Myklebust
2005-04-11 7:48 ` Jakob Oestergaard
2005-04-11 12:35 ` Trond Myklebust
2005-04-11 13:47 ` Jakob Oestergaard
2005-04-11 14:35 ` Trond Myklebust
2005-04-11 14:41 ` Jakob Oestergaard
2005-04-11 15:21 ` Trond Myklebust
2005-04-11 15:42 ` Jakob Oestergaard
2005-04-12 1:03 ` Greg Banks
2005-04-12 9:28 ` Jakob Oestergaard
2005-04-19 19:45 ` Jakob Oestergaard
2005-04-19 22:46 ` Trond Myklebust
2005-04-20 13:57 ` Jakob Oestergaard
2005-04-24 7:15 ` Jakob Oestergaard [this message]
2005-04-25 3:09 ` Trond Myklebust
2005-04-25 13:50 ` Jakob Oestergaard
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=20050424071523.GV17359@unthought.net \
--to=jakob@unthought.net \
--cc=gnb@melbourne.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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