On Fri 18-10-19 07:54:20, Dave Hansen wrote:
> On 10/18/19 12:44 AM, Michal Hocko wrote:
> > How does this compare to
> > http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang@linux.alibaba.com
>
> It's a _bit_ more tied to persistent memory and it appears a bit more
> tied to two t
On Fri, Oct 18, 2019 at 2:40 PM Yang Shi wrote:
>
> On Fri, Oct 18, 2019 at 7:54 AM Dave Hansen wrote:
> >
> > On 10/18/19 12:44 AM, Michal Hocko wrote:
> > > How does this compare to
> > > http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang@linux.alibaba.com
> >
> > It's a _bit_
On Thu, Oct 17, 2019 at 3:58 PM Shakeel Butt wrote:
>
> On Thu, Oct 17, 2019 at 10:20 AM Yang Shi wrote:
> >
> > On Thu, Oct 17, 2019 at 7:26 AM Dave Hansen wrote:
> > >
> > > On 10/16/19 8:45 PM, Shakeel Butt wrote:
> > > > On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen
> > > > wrote:
> > > >> T
On Fri, Oct 18, 2019 at 7:54 AM Dave Hansen wrote:
>
> On 10/18/19 12:44 AM, Michal Hocko wrote:
> > How does this compare to
> > http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang@linux.alibaba.com
>
> It's a _bit_ more tied to persistent memory and it appears a bit more
> tied
On Sat, Oct 19, 2019 at 12:10 AM Dave Hansen wrote:
>
> On 10/18/19 1:11 AM, Suleiman Souhlal wrote:
> > Another issue we ran into, that I think might also apply to this patch
> > series, is that because kernel memory can't be allocated on persistent
> > memory, it's possible for all of DRAM to ge
On 10/18/19 1:11 AM, Suleiman Souhlal wrote:
> Another issue we ran into, that I think might also apply to this patch
> series, is that because kernel memory can't be allocated on persistent
> memory, it's possible for all of DRAM to get filled by user memory and
> have kernel allocations fail even
On 10/18/19 12:44 AM, Michal Hocko wrote:
> How does this compare to
> http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang@linux.alibaba.com
It's a _bit_ more tied to persistent memory and it appears a bit more
tied to two tiers rather something arbitrarily deep. They're pretty
s
On Fri, Oct 18, 2019 at 1:32 AM Dave Hansen wrote:
>
> On 10/17/19 9:01 AM, Suleiman Souhlal wrote:
> > One problem that came up is that if you get into direct reclaim,
> > because persistent memory can have pretty low write throughput, you
> > can end up stalling users for a pretty long time whil
On Wed 16-10-19 15:11:48, Dave Hansen wrote:
> We're starting to see systems with more and more kinds of memory such
> as Intel's implementation of persistent memory.
>
> Let's say you have a system with some DRAM and some persistent memory.
> Today, once DRAM fills up, reclaim will start and some
On Thu, Oct 17, 2019 at 10:20 AM Yang Shi wrote:
>
> On Thu, Oct 17, 2019 at 7:26 AM Dave Hansen wrote:
> >
> > On 10/16/19 8:45 PM, Shakeel Butt wrote:
> > > On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen
> > > wrote:
> > >> This set implements a solution to these problems. At the end of the
> >
On 10/17/19 10:20 AM, Yang Shi wrote:
> On Thu, Oct 17, 2019 at 7:26 AM Dave Hansen wrote:
>> My expectation (and I haven't confirmed this) is that the any memory use
>> is accounted to the owning cgroup, whether it is DRAM or PMEM. memcg
>> limit reclaim and global reclaim both end up doing migr
On 10/17/19 9:58 AM, Shakeel Butt wrote:
>> My expectation (and I haven't confirmed this) is that the any memory use
>> is accounted to the owning cgroup, whether it is DRAM or PMEM. memcg
>> limit reclaim and global reclaim both end up doing migrations and
>> neither should have a net effect on t
On Thu, Oct 17, 2019 at 7:26 AM Dave Hansen wrote:
>
> On 10/16/19 8:45 PM, Shakeel Butt wrote:
> > On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen
> > wrote:
> >> This set implements a solution to these problems. At the end of the
> >> reclaim process in shrink_page_list() just before the last pag
On Thu, Oct 17, 2019 at 7:26 AM Dave Hansen wrote:
>
> On 10/16/19 8:45 PM, Shakeel Butt wrote:
> > On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen
> > wrote:
> >> This set implements a solution to these problems. At the end of the
> >> reclaim process in shrink_page_list() just before the last pag
On Thu, Oct 17, 2019 at 9:32 AM Dave Hansen wrote:
>
> On 10/17/19 9:01 AM, Suleiman Souhlal wrote:
> > One problem that came up is that if you get into direct reclaim,
> > because persistent memory can have pretty low write throughput, you
> > can end up stalling users for a pretty long time whil
On 10/17/19 9:01 AM, Suleiman Souhlal wrote:
> One problem that came up is that if you get into direct reclaim,
> because persistent memory can have pretty low write throughput, you
> can end up stalling users for a pretty long time while migrating
> pages.
Basically, you're saying that memory loa
On Thu, Oct 17, 2019 at 7:14 AM Dave Hansen wrote:
>
> We're starting to see systems with more and more kinds of memory such
> as Intel's implementation of persistent memory.
>
> Let's say you have a system with some DRAM and some persistent memory.
> Today, once DRAM fills up, reclaim will start
On 10/16/19 8:45 PM, Shakeel Butt wrote:
> On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen
> wrote:
>> This set implements a solution to these problems. At the end of the
>> reclaim process in shrink_page_list() just before the last page
>> refcount is dropped, the page is migrated to persistent mem
On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen wrote:
>
> We're starting to see systems with more and more kinds of memory such
> as Intel's implementation of persistent memory.
>
> Let's say you have a system with some DRAM and some persistent memory.
> Today, once DRAM fills up, reclaim will start
We're starting to see systems with more and more kinds of memory such
as Intel's implementation of persistent memory.
Let's say you have a system with some DRAM and some persistent memory.
Today, once DRAM fills up, reclaim will start and some of the DRAM
contents will be thrown out. Allocations
20 matches
Mail list logo
