Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: "Veal, Bryan E" <bryan.e.veal@intel.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: refill_buffers has high CPU utilization
Date: Thu, 25 Mar 2010 22:18:11 +0100	[thread overview]
Message-ID: <20100325211811.GA5768@kernel.dk> (raw)
In-Reply-To: <43F901BD926A4E43B106BF17856F0755A37180B3@orsmsx508.amr.corp.intel.com>

On Thu, Mar 25 2010, Veal, Bryan E wrote:
> Hi all,
> 
> I'm experiencing really high CPU utilization with the refill_buffers option, presumably due to using rand() to generate all the data:
> 
> Output with zero_buffers:
> zero_buffers: (g=0): rw=randwrite, bs=64K-64K/64K-64K, ioengine=psync, iodepth=1
> ...
> zero_buffers: (g=0): rw=randwrite, bs=64K-64K/64K-64K, ioengine=psync, iodepth=1
> zero_buffers: (groupid=0, jobs=32): err= 0: pid=21556
>   write: io=4600MB, bw=156966KB/s, iops=2452, runt= 30009msec
>     clat (usec): min=378, max=139675, avg=13045.49, stdev=1468.67
>     bw (KB/s) : min= 2609, max= 6677, per=3.11%, avg=4886.17, stdev=120.46
>   cpu          : usr=0.30%, sys=1.87%, ctx=2452182, majf=0, minf=11463
> 
> Output with refill_buffers:
> refill_buffers: (g=0): rw=randwrite, bs=64K-64K/64K-64K, ioengine=psync, iodepth=1
> ...
> refill_buffers: (g=0): rw=randwrite, bs=64K-64K/64K-64K, ioengine=psync, iodepth=1
> refill_buffers: (groupid=0, jobs=32): err= 0: pid=21503
>   write: io=4246MB, bw=144867KB/s, iops=2263, runt= 30010msec
>     clat (usec): min=293, max=140908, avg=13969.29, stdev=1837.85
>     bw (KB/s) : min= 1187, max= 6843, per=3.13%, avg=4535.65, stdev=204.58
>   cpu          : usr=37.76%, sys=1.63%, ctx=2286876, majf=0, minf=29750
> 
> While it is useful to write random data, the overhead is prohibitively
> expensive in high-throughput tests.  Would it be a better option to
> allocate a large memory buffer, initialize it with random data, and
> use random offsets within the buffer for data to write to the disk?

I think we should improve it, yes. I like the concept of the data being
pseudo random and non-repetitive at least, since that is guaranteed not
to be compressible. But it doesn't have to be cryptographically strong
by any means, so it should be pretty easy to have a in-fio rand() that
is fast yet good enough for the purpose. > 30% utilization just for
generating random buffers at a fairly slow rate of ~140MB/sec is
definitely excessive and not appropriate.

I'll see to fixing that.

-- 
Jens Axboe


  reply	other threads:[~2010-03-25 21:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-25 20:09 refill_buffers has high CPU utilization Veal, Bryan E
2010-03-25 21:18 ` Jens Axboe [this message]
2010-03-25 22:05   ` Jens Axboe
2010-03-31 12:54     ` Jens Axboe

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=20100325211811.GA5768@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=bryan.e.veal@intel.com \
    --cc=fio@vger.kernel.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