[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACVXFVPE5BMBS-qwgRDxiab9s=SQGYay0VWhU+SGU8Z390hp7g@mail.gmail.com>
Date: Tue, 1 Nov 2016 07:08:24 +0800
From: Ming Lei <tom.leiming@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Jens Axboe <axboe@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-block <linux-block@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Hannes Reinecke <hare@...e.com>,
Mike Christie <mchristi@...hat.com>,
Minfei Huang <mnghuan@...il.com>,
Petr Mladek <pmladek@...e.com>
Subject: Re: [PATCH 15/60] block: loop: comment on direct access to bvec table
On Mon, Oct 31, 2016 at 11:31 PM, Christoph Hellwig <hch@...radead.org> wrote:
> Btw, the lib/iov_iter.c code that iterates over bvec currently
> expects single-page segments. Is the loop code fine with that?
lib/iov_iter.c has switched to bvec iterator already in the mp-bvec
preparing patchset, so every thing will be fine after multipage bvec
is enabled.
Another multipage bvec benefit for lib/iov_iter.c(dio) is that we
can return whole pages in one segment, instead of one page
each time, such as iov_iter_get_pages(), but that can be
a follow-up optimization.
> Even if it is I think we'd be much better off if it becomes multipage
> segment aware.
This patch is for auditing possible effect with multipage bvec, so
looks we should expose as much as possible direct access to
bvec table.
Thanks,
Ming Lei
Powered by blists - more mailing lists