All of lore.kernel.org
 help / color / mirror / Atom feed
From: keith.busch@intel.com (Keith Busch)
Subject: [LSF/MM TOPIC] memory reclaim with NUMA rebalancing
Date: Wed, 30 Jan 2019 11:12:22 -0700	[thread overview]
Message-ID: <20190130181221.GA19525@localhost.localdomain> (raw)
In-Reply-To: <20190130174847.GD18811@dhcp22.suse.cz>

On Wed, Jan 30, 2019@06:48:47PM +0100, Michal Hocko wrote:
> Hi,
> I would like to propose the following topic for the MM track. Different
> group of people would like to use NVIDMMs as a low cost & slower memory
> which is presented to the system as a NUMA node. We do have a NUMA API
> but it doesn't really fit to "balance the memory between nodes" needs.
> People would like to have hot pages in the regular RAM while cold pages
> might be at lower speed NUMA nodes. We do have NUMA balancing for
> promotion path but there is notIhing for the other direction. Can we
> start considering memory reclaim to move pages to more distant and idle
> NUMA nodes rather than reclaim them? There are certainly details that
> will get quite complicated but I guess it is time to start discussing
> this at least.

Yes, thanks for the proposal. I would be very interested in this
discussion for MM. I think some of the details for determining such a
migration path are related to the heterogeneous memory attributes I'm
currently trying to export.

WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <keith.busch@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
	LKML <linux-kernel@vger.kernel.org>,
	linux-nvme@lists.infradead.org
Subject: Re: [LSF/MM TOPIC] memory reclaim with NUMA rebalancing
Date: Wed, 30 Jan 2019 11:12:22 -0700	[thread overview]
Message-ID: <20190130181221.GA19525@localhost.localdomain> (raw)
In-Reply-To: <20190130174847.GD18811@dhcp22.suse.cz>

On Wed, Jan 30, 2019 at 06:48:47PM +0100, Michal Hocko wrote:
> Hi,
> I would like to propose the following topic for the MM track. Different
> group of people would like to use NVIDMMs as a low cost & slower memory
> which is presented to the system as a NUMA node. We do have a NUMA API
> but it doesn't really fit to "balance the memory between nodes" needs.
> People would like to have hot pages in the regular RAM while cold pages
> might be at lower speed NUMA nodes. We do have NUMA balancing for
> promotion path but there is notIhing for the other direction. Can we
> start considering memory reclaim to move pages to more distant and idle
> NUMA nodes rather than reclaim them? There are certainly details that
> will get quite complicated but I guess it is time to start discussing
> this at least.

Yes, thanks for the proposal. I would be very interested in this
discussion for MM. I think some of the details for determining such a
migration path are related to the heterogeneous memory attributes I'm
currently trying to export.


  reply	other threads:[~2019-01-30 18:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 17:48 [LSF/MM TOPIC] memory reclaim with NUMA rebalancing Michal Hocko
2019-01-30 17:48 ` Michal Hocko
2019-01-30 18:12 ` Keith Busch [this message]
2019-01-30 18:12   ` Keith Busch
2019-01-30 23:53 ` Yang Shi
2019-01-30 23:53   ` Yang Shi
2019-01-31  6:49 ` [LSF/MM ATTEND ] " Aneesh Kumar K.V
2019-02-06 19:03   ` Christopher Lameter
2019-02-06 19:03     ` Christopher Lameter
2019-02-22 13:48     ` Jonathan Cameron
2019-02-22 13:48       ` Jonathan Cameron
2019-02-22 14:12     ` Larry Woodman
2019-02-22 14:12       ` Larry Woodman
2019-02-23 13:27   ` Fengguang Wu
2019-02-23 13:27     ` Fengguang Wu
2019-02-23 13:42     ` Fengguang Wu
2019-02-23 13:42       ` Fengguang Wu

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=20190130181221.GA19525@localhost.localdomain \
    --to=keith.busch@intel.com \
    /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.