mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [rfc][patch 2.6.18-rc7] block: explicit plugging
Date: Mon, 18 Sep 2006 10:10:31 -0400	[thread overview]
Message-ID: <20060918141031.GB2884@opti.oraclecorp.com> (raw)
In-Reply-To: <20060916115607.GA16971@wotan.suse.de>

On Sat, Sep 16, 2006 at 01:56:07PM +0200, Nick Piggin wrote:
> Hi,
> 
> I've been tinkering with this idea for a while, and I'd be interested
> in seeing what people think about it. The patch isn't in a great state
> of commenting or splitting ;) but I'd be interested feelings about the
> general approach, and whether I'm going to hit any bad problems (eg.
> with SCSI or IDE).
> 
> Nick
> 
> 
> This is a patch to perform block device plugging explicitly in the submitting
> process context rather than implicitly by the block device.
> 
> There are several advantages to plugging in process context over plugging
> by the block device:
> 
[ ... ]

> On a parallel tiobench benchmark, of the 800 000 calls to __make_request
> performed, this patch avoids 490 000 (62%) of queue_lock aquisitions by
> early merging on the private plugged list.

That is certainly interesting.  Intuitively, I would guess that having
the unplug per-process is going to slow down the case where multiple
procs are banging on the dirty list for multiple files (ie for heavy
memory pressure).  It feels like we're not going to merge as
effectively, but your tiobench test should have hit that.  Did you look
at elevator stats from the test?

> 
> Testing and development is in early stages yet. In particular, the lack of
> a timer based unplug kick probably breaks some block device drivers in
> funny ways (though works here for me with SCSI and UML so far). Also needs
> much wider testing.

Missed unplugs were a nasty problem.  We had a bunch of strange io
stalls and deadlocks without the implicit unplugging, and we also
managed to keep creating new ones as patches rolled into the block
subsystem.  I would really like to keep some kind of catchall implicit
unplug in there.

-chris

  reply	other threads:[~2006-09-18 14:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-16 11:56 Nick Piggin
2006-09-18 14:10 ` Chris Mason [this message]
2006-09-20 14:53   ` Nick Piggin
2006-09-18 20:10 ` Nate Diller
2006-09-20 15:03   ` Nick Piggin
2006-10-06 11:57 ` Jens Axboe
2006-10-08 11:48   ` Nick Piggin
2006-10-08 13:48     ` 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=20060918141031.GB2884@opti.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /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®