[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH v3 14/16] Gut bio_add_page()
- From: Kent Overstreet <koverstreet google com>
- To: Tejun Heo <tj kernel org>
- Cc: axboe kernel dk, dm-devel redhat com, Mike Snitzer <snitzer redhat com>, Dave Chinner <dchinner redhat com>, Dave Chinner <david fromorbit com>, linux-kernel vger kernel org, "Martin K. Petersen" <martin petersen oracle com>, linux-bcache vger kernel org, tytso google com, Mikulas Patocka <mpatocka redhat com>, vgoyal redhat com, bharrosh panasas com, linux-fsdevel vger kernel org, yehuda hq newdream net, drbd-dev lists linbit com, Alasdair G Kergon <agk redhat com>, sage newdream net
- Subject: Re: [dm-devel] [PATCH v3 14/16] Gut bio_add_page()
- Date: Mon, 28 May 2012 23:36:28 -0400
On Tue, May 29, 2012 at 11:15:58AM +0900, Tejun Heo wrote:
> Hello,
>
> On Tue, May 29, 2012 at 12:08:15PM +1000, Dave Chinner wrote:
> > > i thought a bit more about it and the only thing which makes sense to
> > > me is exposing the stripe granularity for striped devices -
> > > ie. something which says "if you go across this boundary, the
> > > performance characteristics including latency might get affected",
> > > which should fit nicely with the rest of topology information.
> > > Martin, adding that shouldn't be difficult, right?
> >
> > We already have the optimal IO size/alignment field in the topology.
> > Doesn't this fit what you want exactly?
>
> I don't know how xfs/ext4 is currently benefiting from
> merge_bvec_fn(), so I'm unsure. If the existing ones are enough,
> great.
Excepting readahead I don't think they are at all.
For readahead all we need is a hint - call it "atomic IO size" or
something. Assuming one of the gazillion things in queue_limits doesn't
already mean that anyways.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]