linux-kernel - Re: [rfc][patch 2.6.18-rc7] block: explicit plugging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Sep 2006 10:10:31 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [rfc][patch 2.6.18-rc7] block: explicit plugging

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/