From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count Date: Sat, 13 Oct 2018 09:47:41 -0700 Message-ID: <20181013164740.GA6593@infradead.org> References: <20181012060014.10242-1-jhubbard@nvidia.com> <20181012060014.10242-5-jhubbard@nvidia.com> <20181013035516.GA18822@dastard> <7c2e3b54-0b1d-6726-a508-804ef8620cfd@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <7c2e3b54-0b1d-6726-a508-804ef8620cfd@nvidia.com> Sender: linux-kernel-owner@vger.kernel.org To: John Hubbard Cc: Dave Chinner , Matthew Wilcox , Michal Hocko , Christopher Lameter , Jason Gunthorpe , Dan Williams , Jan Kara , linux-mm@kvack.org, Andrew Morton , LKML , linux-rdma , linux-fsdevel@vger.kernel.org List-Id: linux-rdma@vger.kernel.org On Sat, Oct 13, 2018 at 12:34:12AM -0700, John Hubbard wrote: > In patch 6/6, pin_page_for_dma(), which is called at the end of get_user_pages(), > unceremoniously rips the pages out of the LRU, as a prerequisite to using > either of the page->dma_pinned_* fields. > > The idea is that LRU is not especially useful for this situation anyway, > so we'll just make it one or the other: either a page is dma-pinned, and > just hanging out doing RDMA most likely (and LRU is less meaningful during that > time), or it's possibly on an LRU list. Have you done any benchmarking what this does to direct I/O performance, especially for small I/O directly to a (fast) block device?