[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c100fcd6-60fb-6650-fdac-7cc3a3bbc464@redhat.com>
Date: Thu, 22 Sep 2022 16:43:57 +0200
From: David Hildenbrand <david@...hat.com>
To: Christoph Hellwig <hch@...radead.org>,
Al Viro <viro@...iv.linux.org.uk>
Cc: Jan Kara <jack@...e.cz>, John Hubbard <jhubbard@...dia.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>,
Miklos Szeredi <miklos@...redi.hu>,
"Darrick J . Wong" <djwong@...nel.org>,
Trond Myklebust <trond.myklebust@...merspace.com>,
Anna Schumaker <anna@...nel.org>,
Logan Gunthorpe <logang@...tatee.com>,
linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 4/7] iov_iter: new iov_iter_pin_pages*() routines
On 22.09.22 16:36, Christoph Hellwig wrote:
> On Tue, Sep 20, 2022 at 06:02:11AM +0100, Al Viro wrote:
>> nvme target: nvme read requests end up with somebody allocating and filling
>> sglist, followed by reading from file into it (using ITER_BVEC). Then the
>> pages are sent out, presumably
>
> Yes.
>
>> . I would be very surprised if it turned out
>> to be anything other than anon pages allocated by the driver, but I'd like
>> to see that confirmed by nvme folks. Probably doesn't need pinning.
>
> They are anon pages allocated by the driver using sgl_alloc().
I assume they are not anon pages as in "PageAnon()", but simply not
pagecache pages, correct?
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists