All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Ravikiran G Thirumalai <kiran@scalex86.org>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Shai Fultheim (Shai@scalex86.org)" <shai@scalex86.org>,
	Alok Kataria <alokk@calsoftinc.com>
Subject: Re: [patch 0/4] ide: Break ide_lock to per-hwgroup lock
Date: Tue, 27 Sep 2005 17:26:42 +0200	[thread overview]
Message-ID: <20050927152641.GF2811@suse.de> (raw)
In-Reply-To: <20050927152026.GC3822@localhost.localdomain>

On Tue, Sep 27 2005, Ravikiran G Thirumalai wrote:
> On Tue, Sep 27, 2005 at 03:36:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On 9/7/05, Jens Axboe <axboe@suse.de> wrote:
> > > On Wed, Sep 07 2005, Ravikiran G Thirumalai wrote:
> > > > On Wed, Sep 07, 2005 at 11:19:24AM +0200, Jens Axboe wrote:
> > > > > On Tue, Sep 06 2005, Ravikiran G Thirumalai wrote:
> > > > > > The following patchset breaks down the global ide_lock to per-hwgroup lock.
> > > > > > We have taken the following approach.
> > > > >
> > > > > Curious, what is the point of this?
> > > > >
> > > >
> > >
> > > I'm asking because I've never heard anyone complain about IDE lock
> > > contention and a proper patch usually comes with analysis of why it is
> > > needed.
> > 
> > Since ide_lock spinlock is used for all drives as queue lock and for all
> > controllers as IDE lock I guess that with multiple controllers there is a lot
> > contention on it...
> > 
> > Breaking ide_lock is fine with me however seeing numbers would
> > greatly help in getting wider acceptance for this change, Ravikiran?
> > 
> 
> With the lock breakdown, Iozone read performance went up by 5.5% on a 2 way
> x86 xeon box, with two hwifs and two processes reading from disks connected
> to each hwif.  There seems to be a small  regression on Iozone write
> tests -- about 1.5%.  Maybe this is measurement noise as there is no apparent
> reason for this.  We plan to run more tests to see if the regression for
> writes is statistically significant.

You should run it eg 10 times on each kernel to get a feel for the
variance of the results. Were you testing 2 or 4 disks?

Some profile information for both kernels would also be paramount.

> Btw, there was some problem with the moving of tuning code in this patchset
> causing disks not to work in DMA mode. We were fixing that; will publish a
> newer patchset with test results soon.

I take it the numbers posted were for DMA enabled on all disks?

-- 
Jens Axboe

  reply	other threads:[~2005-09-27 15:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06 23:33 [patch 0/4] ide: Break ide_lock to per-hwgroup lock Ravikiran G Thirumalai
2005-09-06 23:37 ` [patch 1/4] ide: Break ide_lock -- Move hwif tuning code after hwif_init Ravikiran G Thirumalai
2005-09-06 23:40 ` [patch 2/4] ide: Break ide_lock -- replace ide_lock with hwgroup->lock in core ide Ravikiran G Thirumalai
2005-09-07  6:33   ` Ravikiran G Thirumalai
2005-09-06 23:42 ` [patch 3/4] ide: Break ide_lock -- change controller drivers Ravikiran G Thirumalai
2005-09-06 23:44 ` [patch 4/4] ide: Break ide_lock -- remove ide_lock from piix driver Ravikiran G Thirumalai
2005-09-07 17:06   ` Alan Cox
2005-09-07 17:50     ` Ravikiran G Thirumalai
2005-09-07 18:24       ` Alan Cox
2005-09-07  9:19 ` [patch 0/4] ide: Break ide_lock to per-hwgroup lock Jens Axboe
2005-09-07 19:27   ` Ravikiran G Thirumalai
2005-09-07 19:34     ` Jens Axboe
2005-09-27 13:36       ` Bartlomiej Zolnierkiewicz
2005-09-27 15:20         ` Ravikiran G Thirumalai
2005-09-27 15:26           ` Jens Axboe [this message]
2005-09-27 15:42             ` Ravikiran G Thirumalai
2005-09-27 15:58               ` Jens Axboe
2005-09-07 17:09 ` Alan Cox
2005-09-07 18:16   ` Ravikiran G Thirumalai
2005-09-07 19:06     ` Alan Cox

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=20050927152641.GF2811@suse.de \
    --to=axboe@suse.de \
    --cc=alokk@calsoftinc.com \
    --cc=bzolnier@gmail.com \
    --cc=kiran@scalex86.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shai@scalex86.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.