[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <08749b6a89cf1abe75820ada3663f2a983b0bdc3.camel@wdc.com>
Date: Thu, 21 Feb 2019 23:18:15 +0000
From: Adam Manzanares <Adam.Manzanares@....com>
To: "lsf-pc@...ts.linux-foundation.org"
<lsf-pc@...ts.linux-foundation.org>,
"dave.hansen@...el.com" <dave.hansen@...el.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"willy@...radead.org" <willy@...radead.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"yang.shi@...ux.alibaba.com" <yang.shi@...ux.alibaba.com>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"cl@...ux.com" <cl@...ux.com>,
"jglisse@...hat.com" <jglisse@...hat.com>,
"mhocko@...e.com" <mhocko@...e.com>, "jack@...e.cz" <jack@...e.cz>
Subject: Re: [LSF/MM TOPIC] Page Cache Flexibility for NVM
On Thu, 2019-02-21 at 15:14 -0800, Dave Hansen wrote:
> On 2/21/19 3:11 PM, Adam Manzanares wrote:
> > I am proposing that as an alternative to using NVMs as a NUMA node
> > we expose the NVM through the page cache or a viable alternative
> > and
> > have userspace applications mmap the NVM and hand out memory with
> > their favorite userspace memory allocator.
>
> Are you proposing that the kernel manage this memory (it's managed in
> the buddy lists, for instance) or that something else manage the
> memory,
> like we do for device-dax or HMM?
>
I am proposing we use a device-dax or HMM like model.
Powered by blists - more mailing lists