On Wed, 1 Jul 2020 12:45:17 -0700
David Rientjes wrote:
> On Wed, 1 Jul 2020, Yang Shi wrote:
>
> > > We can do this if we consider pmem not to be a separate memory tier from
> > > the system perspective, however, but rather the socket perspective. In
> > > other words, a node can only demote t
David Rientjes writes:
> On Wed, 1 Jul 2020, Dave Hansen wrote:
>
>> > Could this cause us to break a user's mbind() or allow a user to
>> > circumvent their cpuset.mems?
>>
>> In its current form, yes.
>>
>> My current rationale for this is that while it's not as deferential as
>> it can be t
David Rientjes writes:
> On Wed, 1 Jul 2020, Dave Hansen wrote:
>
>> Even if they don't allocate directly from PMEM, is it OK for such an app
>> to get its cold data migrated to PMEM? That's a much more subtle
>> question and I suspect the kernel isn't going to have a single answer
>> for it. I
On Wed, 1 Jul 2020, Dave Hansen wrote:
> Even if they don't allocate directly from PMEM, is it OK for such an app
> to get its cold data migrated to PMEM? That's a much more subtle
> question and I suspect the kernel isn't going to have a single answer
> for it. I suspect we'll need a cpuset-lev
On Wed, 1 Jul 2020, Yang Shi wrote:
> > We can do this if we consider pmem not to be a separate memory tier from
> > the system perspective, however, but rather the socket perspective. In
> > other words, a node can only demote to a series of exclusive pmem ranges
> > and promote to the same seri
On Wed, 1 Jul 2020, Dave Hansen wrote:
> > Could this cause us to break a user's mbind() or allow a user to
> > circumvent their cpuset.mems?
>
> In its current form, yes.
>
> My current rationale for this is that while it's not as deferential as
> it can be to the user/kernel ABI contract, it'
On 7/1/20 1:54 AM, Huang, Ying wrote:
> Why can not we just bind the memory of the application to node 0, 2, 3
> via mbind() or cpuset.mems? Then the application can allocate memory
> directly from PMEM. And if we bind the memory of the application via
> mbind() to node 0, we can only allocate me
On 6/30/20 10:41 PM, David Rientjes wrote:
On Tue, 30 Jun 2020, Yang Shi wrote:
From: Dave Hansen
If a memory node has a preferred migration path to demote cold pages,
attempt to move those inactive pages to that migration node before
reclaiming. This will better utilize available memory,
On 6/30/20 5:47 PM, David Rientjes wrote:
> On Mon, 29 Jun 2020, Dave Hansen wrote:
>> From: Dave Hansen
>>
>> If a memory node has a preferred migration path to demote cold pages,
>> attempt to move those inactive pages to that migration node before
>> reclaiming. This will better utilize availab
On 6/30/20 10:41 PM, David Rientjes wrote:
> Maybe the strongest advantage of the node abstraction is the ability to
> use autonuma and migrate_pages()/move_pages() API for moving pages
> explicitly? Mempolicies could be used for migration to "top-tier" memory,
> i.e. ZONE_NORMAL or ZONE_MOVABL
David Rientjes writes:
> On Tue, 30 Jun 2020, Yang Shi wrote:
>
>> > > From: Dave Hansen
>> > >
>> > > If a memory node has a preferred migration path to demote cold pages,
>> > > attempt to move those inactive pages to that migration node before
>> > > reclaiming. This will better utilize avai
On Tue, 30 Jun 2020, Yang Shi wrote:
> > > From: Dave Hansen
> > >
> > > If a memory node has a preferred migration path to demote cold pages,
> > > attempt to move those inactive pages to that migration node before
> > > reclaiming. This will better utilize available memory, provide a faster
>
David Rientjes writes:
> On Mon, 29 Jun 2020, Dave Hansen wrote:
>
>> From: Dave Hansen
>>
>> If a memory node has a preferred migration path to demote cold pages,
>> attempt to move those inactive pages to that migration node before
>> reclaiming. This will better utilize available memory, pro
On 6/30/20 5:47 PM, David Rientjes wrote:
On Mon, 29 Jun 2020, Dave Hansen wrote:
From: Dave Hansen
If a memory node has a preferred migration path to demote cold pages,
attempt to move those inactive pages to that migration node before
reclaiming. This will better utilize available memory
On Mon, 29 Jun 2020, Dave Hansen wrote:
> From: Dave Hansen
>
> If a memory node has a preferred migration path to demote cold pages,
> attempt to move those inactive pages to that migration node before
> reclaiming. This will better utilize available memory, provide a faster
> tier than swappin
From: Dave Hansen
If a memory node has a preferred migration path to demote cold pages,
attempt to move those inactive pages to that migration node before
reclaiming. This will better utilize available memory, provide a faster
tier than swapping or discarding, and allow such pages to be reused
16 matches
Mail list logo
