linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: nick <xerofoify@gmail.com>
To: Jeff Moyer <jmoyer@redhat.com>, Dave Chinner <david@fromorbit.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>,
	linux-aio@kvack.org, Miklos Szeredi <mszeredi@suse.cz>,
	Mike Snitzer <snitzer@redhat.com>,
	Ming Lei <tom.leiming@gmail.com>,
	Ming Lei <ming.lei@canonical.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Jianyu Zhan <nasa4836@gmail.com>,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	linux-kernel@vger.kernel.org, Sagi Grimberg <sagig@mellanox.com>,
	Chris Mason <clm@fb.com>,
	dm-devel@redhat.com, target-devel@vger.kernel.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>,
	Mark Rustad <mark.d.rustad@intel.com>,
	Christoph Hellwig <hch@lst.de>, Alasdair Kergon <agk@redhat.com>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	linux-scsi@vger.kernel.org, Namjae Jeon <namjae.jeon@samsung.com>,
	linux-raid@vger.kernel.org, cluster-devel@redhat.com,
	Mel Gorman <mgorman@suse.
Subject: Re: [f2fs-dev] [PATCH 2/2][v2] blk-plug: don't flush nested plug lists
Date: Sat, 11 Apr 2015 00:11:54 -0400	[thread overview]
Message-ID: <55289F0A.1040309@gmail.com> (raw)
In-Reply-To: <x498udzlkkx.fsf@segfault.boston.devel.redhat.com>



On 2015-04-10 05:50 PM, Jeff Moyer wrote:
> Dave Chinner <david@fromorbit.com> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

      reply	other threads:[~2015-04-11  4:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1428347694-17704-1-git-send-email-jmoyer@redhat.com>
     [not found] ` <1428347694-17704-2-git-send-email-jmoyer@redhat.com>
2015-04-07 18:55   ` [PATCH 2/2][v2] blk-plug: don't flush nested plug lists Jeff Moyer
2015-04-08 16:13     ` Christoph Hellwig
2015-04-08 23:02     ` Dave Chinner
2015-04-09  0:54       ` Dave Chinner
2015-04-10 21:50       ` Jeff Moyer
2015-04-11  4:11         ` nick [this message]

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=55289F0A.1040309@gmail.com \
    --to=xerofoify@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=agk@redhat.com \
    --cc=clm@fb.com \
    --cc=cluster-devel@redhat.com \
    --cc=david@fromorbit.com \
    --cc=dm-devel@redhat.com \
    --cc=hch@lst.de \
    --cc=jmoyer@redhat.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mark.d.rustad@intel.com \
    --cc=matthew.r.wilcox@intel.com \
    --cc=mgorman@suse. \
    --cc=mikulas@artax.karlin.mff.cuni.cz \
    --cc=ming.lei@canonical.com \
    --cc=mszeredi@suse.cz \
    --cc=nab@linux-iscsi.org \
    --cc=namjae.jeon@samsung.com \
    --cc=nasa4836@gmail.com \
    --cc=sagig@mellanox.com \
    --cc=snitzer@redhat.com \
    --cc=target-devel@vger.kernel.org \
    --cc=tom.leiming@gmail.com \
    --cc=trond.myklebust@primarydata.com \
    --cc=vdavydov@parallels.com \
    /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;
as well as URLs for NNTP newsgroup(s).