[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160821175844.byt3lejy7mu5sohc@kmo-pixel>
Date: Sun, 21 Aug 2016 09:58:44 -0800
From: Kent Overstreet <kent.overstreet@...il.com>
To: Ming Lei <ming.lei@...onical.com>
Cc: Eric Wheeler <bcache@...ts.ewheeler.net>,
Christoph Hellwig <hch@...radead.org>,
Jens Axboe <axboe@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-block <linux-block@...r.kernel.org>,
Sebastian Roesner <sroesner-kernelorg@...sner-online.de>,
"4.3+" <stable@...r.kernel.org>, Shaohua Li <shli@...com>,
Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH v3] block: make sure big bio is splitted into at most 256
bvecs
On Sun, Aug 21, 2016 at 05:31:33PM +0800, Ming Lei wrote:
> This patch is definitely correct, and I don't see dealing with 'no_merge'
> should be removed.
>
> In this case, the bio is still possible to merge with others because
> it doesn't violate any limit of the queue because it just can't be held in
> 256 bvecs, that means it is correct to clear no_merge for this situation.
>
> Also I don't think it is complicated or ugly to deal with the flag.
It's extra unnecessary code. All other things being equal, less code is always
better than more code. It works just fine without it, what's the justification
for adding the flag?
Don't be so dismissive of other maintainer's concerns, we've got to deal with
this code too. Especially when I and Christoph are agreeing on something - how
often does that happen?
Powered by blists - more mailing lists