All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
To: linux-btrace@vger.kernel.org
Subject: Re: blktrace2: Fully working variant... Needs testing... :-)
Date: Thu, 05 Feb 2009 11:42:00 +0000	[thread overview]
Message-ID: <498AD088.4070000@hp.com> (raw)
In-Reply-To: <498A0D14.3080000@hp.com>

Alan D. Brunelle wrote:
> I'm seeing some positive results on my 16-way amd64 box (w/ 48 FC disks
> & 48 CCISS disks) - less intrusive blktrace()ing, resulting in more
> benchmark through put for example.
> 
> It seems to be pretty valgrind clean (only issue I've seen is in
> inet_ntoa: man page says it uses static storage, but valgrind claims it
> uses malloc - nothing for us to be concerned with).
> 
> Anyways, I'm putting this out there whilst I do some more testing to
> verify things.
> 

Some good news: doing my previously reported testing on the balanced
configuration completed successfully. (mkfs on large numbers of CCISS
disks, tracing to a large number of FC disks)

What is more, it appears to be a little better in terms of fewer drops &
fewer drop cases - results below are in percent drops:

blktrace:

  -b      4     8    16    32    64   128   256   512  1024  2048  4096
-n   |----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
    4|                                            4.4   0.0   0.0   0.0
    8|                                      1.5   0.0
   16|                                0.1         0.0
   32|                          0.8               0.0
   64|                    1.1
  128|              0.8
  256|        2.6
  512|  2.3
 1024|  0.5
 2048|  0.1
 4096|  0.0

blktrace2:

  -b     4     8    16    32    64   128   256   512  1024  2048  4096
-n   |----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
    4|                                            0.2   0.0   0.0   0.0
    8|                                      0.1   0.0
   16|                                0.0         0.0
   32|                          0.0               0.0
   64|                    0.1
  128|              0.1
  256|        0.1
  512|  0.2
 1024|  0.0
 2048|  0.0
 4096|  0.0

 The goal now will be to try and see if I can wiggle out the remaining
 0.1 or 0.2% drops...

 Alan

  reply	other threads:[~2009-02-05 11:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-04 21:48 blktrace2: Fully working variant... Needs testing... :-) Alan D. Brunelle
2009-02-05 11:42 ` Alan D. Brunelle [this message]
2009-02-06  8:04 ` Jens Axboe
2009-02-06 11:34 ` Alan D. Brunelle
2009-02-06 15:02 ` M. Edward (Ed) Borasky
2009-02-06 15:21 ` Alan D. Brunelle

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=498AD088.4070000@hp.com \
    --to=alan.brunelle@hp.com \
    --cc=linux-btrace@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 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.