xfs
[Top] [All Lists]

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

To: Jeff Moyer <jmoyer@xxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [f2fs-dev] [PATCH 2/2][v2] blk-plug: don't flush nested plug lists
From: nick <xerofoify@xxxxxxxxx>
Date: Sat, 11 Apr 2015 00:11:54 -0400
Cc: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx>, linux-aio@xxxxxxxxx, Miklos Szeredi <mszeredi@xxxxxxx>, Mike Snitzer <snitzer@xxxxxxxxxx>, Ming Lei <tom.leiming@xxxxxxxxx>, Ming Lei <ming.lei@xxxxxxxxxxxxx>, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>, Jianyu Zhan <nasa4836@xxxxxxxxx>, "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Sagi Grimberg <sagig@xxxxxxxxxxxx>, Chris Mason <clm@xxxxxx>, dm-devel@xxxxxxxxxx, target-devel@xxxxxxxxxxxxxxx, Andreas Dilger <adilger.kernel@xxxxxxxxx>, Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>, Mark Rustad <mark.d.rustad@xxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>, Alasdair Kergon <agk@xxxxxxxxxx>, Matthew Wilcox <matthew.r.wilcox@xxxxxxxxx>, linux-scsi@xxxxxxxxxxxxxxx, Namjae Jeon <namjae.jeon@xxxxxxxxxxx>, linux-raid@xxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, Mel Gorman <mgorman@xxxxxxx>, Suleiman Souhlal <suleiman@xxxxxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, Rik van Riel <riel@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, xfs@xxxxxxxxxxx, Fabian Frederick <fabf@xxxxxxxxx>, Joe Perches <joe@xxxxxxxxxxx>, Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Jaegeuk Kim <jaegeuk@xxxxxxxxxx>, Steven Whitehouse <swhiteho@xxxxxxxxxx>, Vlastimil Babka <vbabka@xxxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, Michal Hocko <mhocko@xxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, Fengguang Wu <fengguang.wu@xxxxxxxxx>, Theodore Ts'o <tytso@xxxxxxx>, "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>, Wang Sheng-Hui <shhuiw@xxxxxxxxx>, Josef Bacik <jbacik@xxxxxx>, David Sterba <dsterba@xxxxxxx>, linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, Johannes Weiner <hannes@xxxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Weston Andros Adamson <dros@xxxxxxxxxxxxxxx>, Anna Schumaker <anna.schumaker@xxxxxxxxxx>, "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, Roger Pau Monn?? <roger.pau@xxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=u3ImffvjPW9HSlc55/O3toQVqcTaFR2igpBkxuUl344=; b=ynuJJyL2spAPqnRuc6gqjR5F0KUs1tbH+AfGIeIb8VLYFw1gmK9sHTaZzV8+9SgHoE AtB91v70DzEw+jqBXxrpMS9cN8Tuum5rR0TFgZoveJSq4CHvIEqVfLnh/VYW+WTPOxdZ 8dVNzkCH00BflinTNmid3+cRPgts++2cEfZjCccx7ieJpTfhVntwGaoI9HUO4g28ro4z koOw9pgFMDbShsbE+jPff/TmL8aRuA+dvJ2IdrlIda4cHGzIsEU9Mm0ncWx1Mp6Cl9CJ oiD4MIoAWZefx4Pxg2UbxOZunMrbzfFRCkXegqB2uVCn1vB6PDJZ4eftx6/9W7MNVm4i 90vA==
In-reply-to: <x498udzlkkx.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <1428347694-17704-1-git-send-email-jmoyer@xxxxxxxxxx> <1428347694-17704-2-git-send-email-jmoyer@xxxxxxxxxx> <x49wq1nrcoe.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20150408230203.GG15810@dastard> <x498udzlkkx.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 2015-04-10 05:50 PM, Jeff Moyer wrote:
> 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.
> 
> -Jeff
> 
Jeff,
Would you mind sending your test reports to the list so we can see what 
workloads
and tests your running your patch under. This is due to me and the others 
perhaps
being able to give input into the other major benchmarks or workloads we need to
test too in order to see if there are any regressions with your patch.
Thanks,
Nick

> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 

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