mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Jeremy Higdon <jeremy@sgi.com>
Cc: linux-kernel@vger.kernel.org, jbarnes@sgi.com, axboe@suse.de
Subject: Re: [PATCH] per-backing dev unplugging #2
Date: Tue, 16 Mar 2004 17:36:18 +1100	[thread overview]
Message-ID: <4056A062.6040203@cyberone.com.au> (raw)
In-Reply-To: <20040316052256.GA647970@sgi.com>



Jeremy Higdon wrote:

>| Hi,
>| 
>| Final version, unless something stupid pops up. Changes:
>| 
>| - Adapt to 2.6.4-mm1
>| - Cleaned up the dm bits, much nicer with the lockless unplugging
>|   (thanks Joe)
>| - md and loop unplugging, stacked devices should unplug their targets.
>|   Otherwise they'll end up waiting for the unplug timer, which sucks.
>| - XFS fixed up, I hope. XFS folks still encouraged to look at this,
>|   looks better this time around though (and works, I tested).
>| - blk_run_* inlined in blkdev.h
>| 
>| Against 2.6.4-mm1 (note you need other attached patch to boot it).
>
>I got a chance to try this.
>
>It makes a huge improvement.
>
>Prior to the last per-cpu patch, I was getting about 75000 to 80000
>IOPS at 100% cpu usage.
>
>With the per-cpu patch, that went up to 110000 IOPS at 100% CPU.
>
>With this patch, I'm seeing 200000 IOPS at about 65% CPU usage.
>
>So it makes a tremendous improvement in I/O scalability, dramatically
>improving performance in small size I/O, high I/O count workloads.
>
>My tests were on an 8 CPU x 1300 MHz Altix with 64 disks.
>
>

Nice - so if you had enough IO capacity to saturate the CPUs it
might come close to a 4x improvement - and this sounds like one
of your baby systems?

I wonder why nobody's complained about this before?


  reply	other threads:[~2004-03-16  8:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-16  5:22 Jeremy Higdon
2004-03-16  6:36 ` Nick Piggin [this message]
2004-03-16  7:20   ` Jeremy Higdon
2004-03-16  7:38     ` Jens Axboe
2004-03-17  0:23       ` Jeremy Higdon
2004-03-16  7:46     ` Nick Piggin
2004-03-16  7:29 ` Jens Axboe
2004-03-16 17:20 ` Jesse Barnes
  -- strict thread matches above, loose matches on Subject: below --
2004-03-11  8:36 Jens Axboe
2004-03-11 22:44 ` Nathan Scott
2004-03-12  1:23 ` William Lee Irwin III
2004-03-12  6:41 ` Ingo Oeser
2004-03-12  8:04   ` Jens Axboe
2004-03-12 19:51 ` Chris Mason
2004-03-12 20:03   ` Andrew Morton
2004-03-12 20:02     ` Jens Axboe
2004-03-12 20:34       ` Chris Mason
2004-03-12 20:34         ` Jens Axboe
2004-03-12 20:41           ` Chris Mason
2004-03-12 20:51             ` Jens Axboe
2004-03-14 20:43               ` Chris Mason
2004-03-14 20:47                 ` Jens Axboe
2004-03-14 20:57                   ` Chris Mason
2004-03-14 21:04                   ` Andrew Morton
2004-03-14 21:09                     ` Jens Axboe
2004-03-15 21:58                       ` Chris Mason
2004-03-12 20:06     ` Chris Mason

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=4056A062.6040203@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=axboe@suse.de \
    --cc=jbarnes@sgi.com \
    --cc=jeremy@sgi.com \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®