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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.