All of lore.kernel.org
 help / color / mirror / Atom feed
From: "ying.huang@intel.com" <ying.huang@intel.com>
To: Jagdish Gediya <jvgediya@linux.ibm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com,
	baolin.wang@linux.alibaba.com, dave.hansen@linux.intel.com
Subject: Re: [PATCH v2 1/5] mm: demotion: Set demotion list differently
Date: Thu, 14 Apr 2022 16:57:04 +0800	[thread overview]
Message-ID: <d330a8942933e7c0fd4ea35b2c96948cd034aae2.camel@intel.com> (raw)
In-Reply-To: <YlffwGJg/RWCYja7@li-6e1fa1cc-351b-11b2-a85c-b897023bb5f3.ibm.com>

On Thu, 2022-04-14 at 14:18 +0530, Jagdish Gediya wrote:
> On Thu, Apr 14, 2022 at 03:09:42PM +0800, ying.huang@intel.com wrote:
> > On Wed, 2022-04-13 at 14:52 +0530, Jagdish Gediya wrote:
> > > Sharing used_targets between multiple nodes in a single
> > > pass limits some of the opportunities for demotion target
> > > sharing.
> > > 
> > > Don't share the used targets between multiple nodes in a
> > > single pass, instead accumulate all the used targets in
> > > source nodes shared by all pass, and reset 'used_targets'
> > > to source nodes while finding demotion targets for any new
> > > node.
> > > 
> > > This results into some more opportunities to share demotion
> > > targets between multiple source nodes, e.g. with below NUMA
> > > topology, where node 0 & 1 are cpu + dram nodes, node 2 & 3
> > > are equally slower memory only nodes, and node 4 is slowest
> > > memory only node,
> > > 
> > > available: 5 nodes (0-4)
> > > node 0 cpus: 0 1
> > > node 0 size: n MB
> > > node 0 free: n MB
> > > node 1 cpus: 2 3
> > > node 1 size: n MB
> > > node 1 free: n MB
> > > node 2 cpus:
> > > node 2 size: n MB
> > > node 2 free: n MB
> > > node 3 cpus:
> > > node 3 size: n MB
> > > node 3 free: n MB
> > > node 4 cpus:
> > > node 4 size: n MB
> > > node 4 free: n MB
> > > node distances:
> > > node   0   1   2   3   4
> > >   0:  10  20  40  40  80
> > >   1:  20  10  40  40  80
> > >   2:  40  40  10  40  80
> > >   3:  40  40  40  10  80
> > >   4:  80  80  80  80  10
> > > 
> > > The existing implementation gives below demotion targets,
> > > 
> > > node    demotion_target
> > >  0              3, 2
> > >  1              4
> > >  2              X
> > >  3              X
> > >  4              X
> > > 
> > > With this patch applied, below are the demotion targets,
> > > 
> > > node    demotion_target
> > >  0              3, 2
> > >  1              3, 2
> > >  2              4
> > >  3              4
> > >  4              X
> > > 
> > > e.g. with below NUMA topology, where node 0, 1 & 2 are
> > > cpu + dram nodes and node 3 is slow memory node,
> > > 
> > > available: 4 nodes (0-3)
> > > node 0 cpus: 0 1
> > > node 0 size: n MB
> > > node 0 free: n MB
> > > node 1 cpus: 2 3
> > > node 1 size: n MB
> > > node 1 free: n MB
> > > node 2 cpus: 4 5
> > > node 2 size: n MB
> > > node 2 free: n MB
> > > node 3 cpus:
> > > node 3 size: n MB
> > > node 3 free: n MB
> > > node distances:
> > > node   0   1   2   3
> > >   0:  10  20  20  40
> > >   1:  20  10  20  40
> > >   2:  20  20  10  40
> > >   3:  40  40  40  10
> > > 
> > > The existing implementation gives below demotion targets,
> > > 
> > > node    demotion_target
> > >  0              3
> > >  1              X
> > >  2              X
> > >  3              X
> > > 
> > > With this patch applied, below are the demotion targets,
> > > 
> > > node    demotion_target
> > >  0              3
> > >  1              3
> > >  2              3
> > >  3              X
> > > 
> > 
> > With the [PATCH v1], you have describe the demotion order changes for
> > the following system, I guess there's no change with [PATCH v2]?
> 
> Yes, there is no change with v2.
> 
> > With below NUMA topology, where node 0 & 2 are cpu + dram
> > nodes and node 1 & 3 are slow memory nodes,
> > 
> > available: 4 nodes (0-3)
> > node 0 cpus: 0 1
> > node 0 size: n MB
> > node 0 free: n MB
> > node 1 cpus:
> > node 1 size: n MB
> > node 1 free: n MB
> > node 2 cpus: 2 3
> > node 2 size: n MB
> > node 2 free: n MB
> > node 3 cpus:
> > node 3 size: n MB
> > node 3 free: n MB
> > node distances:
> > node   0   1   2   3
> >   0:  10  40  20  80
> >   1:  40  10  80  80
> >   2:  20  80  10  40
> >   3:  80  80  40  10
> > 
> > And, what is the demotion order for the following system with [PATCH
> > v2]?
> > 
> > Node 0 & 2 are cpu + dram nodes and node 1 are slow
> > memory node near node 0,
> > 
> > available: 3 nodes (0-2)
> > node 0 cpus: 0 1
> > node 0 size: n MB
> > node 0 free: n MB
> > node 1 cpus:
> > node 1 size: n MB
> > node 1 free: n MB
> > node 2 cpus: 2 3
> > node 2 size: n MB
> > node 2 free: n MB
> > node distances:
> > node   0   1   2
> >   0:  10  40  20
> >   1:  40  10  80
> >   2:  20  80  10
> 
> node 1 is demotion target for both node 0 and node 2 with this patch.
> node 1 is demotion target only for node 0 with existing implementation,
> however if node 1 is near to node 2 instead of node 0, still existing
> implementation will give node 1 as demotion target only for node 0 which
> is not the correct behavior.
> 
> for both the scenario, with this patch applied, node 1 will be demotion
> target for both 0 and 2.
> 

Sounds good!  Thanks.

Acked-by: "Huang, Ying" <ying.huang@intel.com>

> > Best Regards,
> > Huang, Ying
> > 
> > 
> > [snip]
> > 
> > 
> > 
> Best regards,
> Jagdish



  reply	other threads:[~2022-04-14  8:57 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13  9:22 [PATCH v2 0/5] mm: demotion: Introduce new node state N_DEMOTION_TARGETS Jagdish Gediya
2022-04-13  9:22 ` [PATCH v2 1/5] mm: demotion: Set demotion list differently Jagdish Gediya
2022-04-14  7:09   ` ying.huang
2022-04-14  8:48     ` Jagdish Gediya
2022-04-14  8:57       ` ying.huang [this message]
2022-04-14  8:55   ` Baolin Wang
2022-04-14  9:02   ` Jonathan Cameron
2022-04-14 10:40     ` Jagdish Gediya
2022-04-21  6:13   ` ying.huang
2022-04-13  9:22 ` [PATCH v2 2/5] mm: demotion: Add new node state N_DEMOTION_TARGETS Jagdish Gediya
2022-04-21  4:33   ` Wei Xu
2022-04-13  9:22 ` [PATCH v2 3/5] mm: demotion: Add support to set targets from userspace Jagdish Gediya
2022-04-21  4:26   ` Wei Xu
2022-04-22  9:13     ` Jagdish Gediya
2022-04-21  5:31   ` Wei Xu
2022-04-13  9:22 ` [PATCH v2 4/5] device-dax/kmem: Set node state as N_DEMOTION_TARGETS Jagdish Gediya
2022-04-13  9:22 ` [PATCH v2 5/5] mm: demotion: Build demotion list based on N_DEMOTION_TARGETS Jagdish Gediya
2022-04-13 21:44 ` [PATCH v2 0/5] mm: demotion: Introduce new node state N_DEMOTION_TARGETS Andrew Morton
2022-04-14 10:16   ` Jagdish Gediya
2022-04-14  7:00 ` ying.huang
2022-04-14 10:19   ` Jagdish Gediya
2022-04-21  3:11   ` Yang Shi
2022-04-21  5:41     ` Wei Xu
2022-04-21  6:24       ` ying.huang
2022-04-21  6:49         ` Wei Xu
2022-04-21  7:08           ` ying.huang
2022-04-21  7:29             ` Wei Xu
2022-04-21  7:45               ` ying.huang
2022-04-21 18:26                 ` Wei Xu
2022-04-22  0:58                   ` ying.huang
2022-04-22  4:46                     ` Wei Xu
2022-04-22  5:40                       ` ying.huang
2022-04-22  6:11                         ` Wei Xu
2022-04-22  6:13                         ` Wei Xu
2022-04-22  6:21                           ` ying.huang
2022-04-22 11:00                             ` Jagdish Gediya
2022-04-22 16:43                               ` Wei Xu
2022-04-22 17:29                                 ` Yang Shi
2022-04-24  3:02                               ` ying.huang
2022-04-25  3:50                                 ` Aneesh Kumar K.V
2022-04-25  6:10                                   ` ying.huang
2022-04-25  8:09                                     ` Aneesh Kumar K V
2022-04-25  8:54                                       ` Aneesh Kumar K V
2022-04-25 20:17                                       ` Davidlohr Bueso
2022-04-26  8:42                                       ` ying.huang
2022-04-26  9:02                                         ` Aneesh Kumar K V
2022-04-26  9:44                                           ` ying.huang
2022-04-27  4:27                                         ` Wei Xu
2022-04-25  7:26                                 ` Jagdish Gediya
2022-04-25 16:56                                 ` Wei Xu
2022-04-27  5:06                                   ` Aneesh Kumar K V
2022-04-27 18:27                                     ` Wei Xu
2022-04-28  0:56                                       ` ying.huang
2022-04-28  4:11                                         ` Wei Xu
2022-04-28 17:14                                           ` Yang Shi
2022-04-29  1:27                                             ` Alistair Popple
2022-04-29  2:21                                               ` ying.huang
2022-04-29  2:58                                                 ` Wei Xu
2022-04-29  3:27                                                   ` ying.huang
2022-04-29  4:45                                                     ` Alistair Popple
2022-04-29 18:53                                                       ` Yang Shi
2022-04-29 18:52                                                   ` Yang Shi
2022-04-27  7:11                                   ` ying.huang
2022-04-27 16:27                                     ` Wei Xu
2022-04-28  8:37                                       ` ying.huang
2022-04-28 19:30                                         ` Chen, Tim C
2022-04-30  2:21                                           ` Wei Xu
2022-04-21 17:56       ` Yang Shi
2022-04-21 23:48         ` ying.huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d330a8942933e7c0fd4ea35b2c96948cd034aae2.camel@intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jvgediya@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.