[Top] [All Lists]

Re: [PATCH 2/2][v2] blk-plug: don't flush nested plug lists

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/2][v2] blk-plug: don't flush nested plug lists
From: Jeff Moyer <jmoyer@xxxxxxxxxx>
Date: Fri, 10 Apr 2015 17:50:06 -0400
Cc: Jens Axboe <axboe@xxxxxxxxx>, Ming Lei <tom.leiming@xxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Roger Pau Monn?? <roger.pau@xxxxxxxxxx>, Alasdair Kergon <agk@xxxxxxxxxx>, Mike Snitzer <snitzer@xxxxxxxxxx>, Neil Brown <neilb@xxxxxxx>, "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>, Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, Chris Mason <clm@xxxxxx>, Josef Bacik <jbacik@xxxxxx>, David Sterba <dsterba@xxxxxxx>, "Theodore Ts'o" <tytso@xxxxxxx>, Andreas Dilger <adilger.kernel@xxxxxxxxx>, Jaegeuk Kim <jaegeuk@xxxxxxxxxx>, Changman Lee <cm224.lee@xxxxxxxxxxx>, Steven Whitehouse <swhiteho@xxxxxxxxxx>, Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Rik van Riel <riel@xxxxxxxxxx>, Johannes Weiner <hannes@xxxxxxxxxxx>, Mel Gorman <mgorman@xxxxxxx>, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>, Anna Schumaker <anna.schumaker@xxxxxxxxxx>, xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxx>, Weston Andros Adamson <dros@xxxxxxxxxxxxxxx>, "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>, Sagi Grimberg <sagig@xxxxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, Fabian Frederick <fabf@xxxxxxxxx>, Matthew Wilcox <matthew.r.wilcox@xxxxxxxxx>, Ming Lei <ming.lei@xxxxxxxxxxxxx>, "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, Wang Sheng-Hui <shhuiw@xxxxxxxxx>, Michal Hocko <mhocko@xxxxxxx>, Joe Perches <joe@xxxxxxxxxxx>, Miklos Szeredi <mszeredi@xxxxxxx>, Namjae Jeon <namjae.jeon@xxxxxxxxxxx>, Mark Rustad <mark.d.rustad@xxxxxxxxx>, Jianyu Zhan <nasa4836@xxxxxxxxx>, Fengguang Wu <fengguang.wu@xxxxxxxxx>, Vladimir Davydov <vdavydov@xxxxxxxxxxxxx>, Vlastimil Babka <vbabka@xxxxxxx>, Suleiman Souhlal <suleiman@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, dm-devel@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-raid@xxxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, target-devel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-aio@xxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150408230203.GG15810@dastard> (Dave Chinner's message of "Thu, 9 Apr 2015 09:02:03 +1000")
References: <1428347694-17704-1-git-send-email-jmoyer@xxxxxxxxxx> <1428347694-17704-2-git-send-email-jmoyer@xxxxxxxxxx> <x49wq1nrcoe.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20150408230203.GG15810@dastard>
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Dave Chinner <david@xxxxxxxxxxxxx> writes:

> On Tue, Apr 07, 2015 at 02:55:13PM -0400, Jeff Moyer wrote:
>> The way the on-stack plugging currently works, each nesting level
>> flushes its own list of I/Os.  This can be less than optimal (read
>> awful) for certain workloads.  For example, consider an application
>> that issues asynchronous O_DIRECT I/Os.  It can send down a bunch of
>> I/Os together in a single io_submit call, only to have each of them
>> dispatched individually down in the bowels of the dirct I/O code.
>> The reason is that there are blk_plug-s instantiated both at the upper
>> call site in do_io_submit and down in do_direct_IO.  The latter will
>> submit as little as 1 I/O at a time (if you have a small enough I/O
>> size) instead of performing the batching that the plugging
>> infrastructure is supposed to provide.
> I'm wondering what impact this will have on filesystem metadata IO
> that needs to be issued immediately. e.g. we are doing writeback, so
> there is a high level plug in place and we need to page in btree
> blocks to do extent allocation. We do readahead at this point,
> but it looks like this change will prevent the readahead from being
> issued by the unplug in xfs_buf_iosubmit().

I'm not ignoring you, Dave, I'm just doing some more investigation and
testing.  It's taking longer than I had hoped.


<Prev in Thread] Current Thread [Next in Thread>