[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2367ff26-809c-da94-a8f0-e921bdc4862a@nvidia.com>
Date: Wed, 17 Oct 2018 17:03:03 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Michal Hocko <mhocko@...nel.org>
CC: Jan Kara <jack@...e.cz>, Dave Chinner <david@...morbit.com>,
Matthew Wilcox <willy@...radead.org>,
Christopher Lameter <cl@...ux.com>,
Jason Gunthorpe <jgg@...pe.ca>,
Dan Williams <dan.j.williams@...el.com>, <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-rdma <linux-rdma@...r.kernel.org>,
<linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count
On 10/17/18 4:09 AM, Michal Hocko wrote:
> On Tue 16-10-18 18:48:23, John Hubbard wrote:
> [...]
>> It's hard to say exactly what the active/inactive/unevictable list should
>> be when DMA is done and put_user_page*() is called, because we don't know
>> if some device read, wrote, or ignored any of those pages. Although if
>> put_user_pages_dirty() is called, that's an argument for "active", at least.
>
> Any reason to not use putback_lru_page?
That does help with which LRU to use. I guess I'd still need to track whether
a page was on an LRU when get_user_pages() was called, because it seems
that that is not necessarily always the case. And putback_lru_page() definitely
wants to deal with a page that *was* previously on an LRU.
>
> Please note I haven't really got through your patches to have a wider
> picture of the change so this is just hint for the LRU part of the
> issue.
>
Understood, and the hints are much appreciated.
--
thanks,
John Hubbard
NVIDIA
Powered by blists - more mailing lists