[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120528230208.GA20954@dhcp-172-17-108-109.mtv.corp.google.com>
Date: Tue, 29 May 2012 08:02:08 +0900
From: Tejun Heo <tj@...nel.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Alasdair G Kergon <agk@...hat.com>,
Kent Overstreet <koverstreet@...gle.com>,
Mike Snitzer <snitzer@...hat.com>,
linux-kernel@...r.kernel.org, linux-bcache@...r.kernel.org,
dm-devel@...hat.com, linux-fsdevel@...r.kernel.org,
axboe@...nel.dk, yehuda@...newdream.net, vgoyal@...hat.com,
bharrosh@...asas.com, sage@...dream.net, drbd-dev@...ts.linbit.com,
Dave Chinner <dchinner@...hat.com>, tytso@...gle.com,
"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCH v3 14/16] Gut bio_add_page()
(cc'ing Martin K. Petersen, hi!)
On Tue, May 29, 2012 at 06:38:39AM +0900, Tejun Heo wrote:
> > With this patchset, you don't have to expose all the limits. You can
> > expose just a few most useful limits to avoid bio split in the cases
> > described above.
>
> Yeah, if that actually helps, sure. From what I read, dm is already
> (ab)using merge_bvec_fn() like that anyway.
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?
Thanks.
--
tejun
--
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/
Powered by blists - more mailing lists