[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160406024031.GB7793@kmo-pixel>
Date: Tue, 5 Apr 2016 18:40:31 -0800
From: Kent Overstreet <kent.overstreet@...il.com>
To: Ming Lei <ming.lei@...onical.com>
Cc: Jens Axboe <axboe@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-block@...r.kernel.org, Christoph Hellwig <hch@...radead.org>,
Eric Wheeler <bcache@...ts.ewheeler.net>,
Sebastian Roesner <sroesner-kernelorg@...sner-online.de>,
"4.2+" <stable@...r.kernel.org>, Shaohua Li <shli@...com>
Subject: Re: [PATCH] block: make sure big bio is splitted into at most 256
bvecs
On Wed, Apr 06, 2016 at 10:37:05AM +0800, Ming Lei wrote:
> On Wed, Apr 6, 2016 at 10:34 AM, Kent Overstreet
> <kent.overstreet@...il.com> wrote:
> > On Wed, Apr 06, 2016 at 10:30:22AM +0800, Ming Lei wrote:
> >> Now limit.max_segments is for limiting segments from hw view, one this
> >> segment may include lots of pages/bvecs.
> >>
> >> The current bio_clone() issue is that we can't clone from one bio which
> >> includes more than 256 bvecs, maybe all these 256 bvecs belong to
> >> one same hw segment.
> >
> > So the distinction is purely a post multipage bvec thing?
>
> Even after multipage bvec is applied, the limit for max bvecs is still needed
> for some cases like bio bounce, in which bio_clone() need to
> clone single page bvec.
s/max bvecs/max pages/?
What I meant is that until we have multipage bvecs, unless I'm missing something
max_segments is exactly what we want. After multipage bvecs, things do get more
complicated I agree.
Powered by blists - more mailing lists