All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Leonardo Bras <leonardo@linux.ibm.com>,
	Nathan Lynch <nathanl@linux.ibm.com>,
	Allison Randal <allison@lohutok.net>,
	Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	lantianyu1986@gmail.com,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul
Date: Wed, 22 Jan 2020 19:38:09 +0100	[thread overview]
Message-ID: <20200122183809.GB29276@dhcp22.suse.cz> (raw)
In-Reply-To: <626d344e-8243-c161-cd07-ed1276eba73d@redhat.com>

On Wed 22-01-20 19:15:47, David Hildenbrand wrote:
> On 22.01.20 17:46, Michal Hocko wrote:
> > On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
[...]
> >> Especially interesting for IBM z Systems, whereby memory
> >> onlining/offlining will trigger the actual population of memory in the
> >> hypervisor. So if an admin wants to offline some memory (to give it back
> >> to the hypervisor), it would use lsmem to identify such blocks first,
> >> instead of trying random blocks until one offlining request succeeds.
> > 
> > I am sorry for being dense here but I still do not understand why s390
> 
> It's good that we talk about it :) It's hard to reconstruct actual use
> cases from tools and some documentation only ...
> 
> Side note (just FYI): One difference on s390x compared to other
> architectures (AFAIKS) is that once memory is offline, you might not be
> allowed (by the hypervisor) to online it again - because it was
> effectively unplugged. Such memory is not removed via remove_memory(),
> it's simply kept offline.

I have a very vague understanding of s390 specialities but this is not
really relevant to the discussion AFAICS because this happens _after_
offlining.
 
> > and the way how it does the hotremove matters here. Afterall there are
> > no arch specific operations done until the memory is offlined. Also
> > randomly checking memory blocks and then hoping that the offline will
> > succeed is not way much different from just trying the offline the
> > block. Both have to crawl through the pfn range and bail out on the
> > unmovable memory.
> 
> I think in general we have to approaches to memory unplugging.
> 
> 1. Know explicitly what you want to unplug (e.g., a DIMM spanning
> multiple memory blocks).
> 
> 2. Find random memory blocks you can offline/unplug.
> 
> 
> For 1, I think we both agree that we don't need this. Just try to
> offline and you know if it worked.
> 
> Now of course, for 2 you can try random blocks until you succeeded. From
> a sysadmin point of view that's very inefficient. From a powerpc-utils
> point of view, that's inefficient.

How exactly is check + offline more optimal then offline which makes
check as its first step? I will get to your later points after this is
clarified.
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>, Paul Mackerras <paulus@samba.org>,
	Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	Leonardo Bras <leonardo@linux.ibm.com>,
	Dan Williams <dan.j.williams@intel.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Allison Randal <allison@lohutok.net>,
	lantianyu1986@gmail.com
Subject: Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul
Date: Wed, 22 Jan 2020 19:38:09 +0100	[thread overview]
Message-ID: <20200122183809.GB29276@dhcp22.suse.cz> (raw)
In-Reply-To: <626d344e-8243-c161-cd07-ed1276eba73d@redhat.com>

On Wed 22-01-20 19:15:47, David Hildenbrand wrote:
> On 22.01.20 17:46, Michal Hocko wrote:
> > On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
[...]
> >> Especially interesting for IBM z Systems, whereby memory
> >> onlining/offlining will trigger the actual population of memory in the
> >> hypervisor. So if an admin wants to offline some memory (to give it back
> >> to the hypervisor), it would use lsmem to identify such blocks first,
> >> instead of trying random blocks until one offlining request succeeds.
> > 
> > I am sorry for being dense here but I still do not understand why s390
> 
> It's good that we talk about it :) It's hard to reconstruct actual use
> cases from tools and some documentation only ...
> 
> Side note (just FYI): One difference on s390x compared to other
> architectures (AFAIKS) is that once memory is offline, you might not be
> allowed (by the hypervisor) to online it again - because it was
> effectively unplugged. Such memory is not removed via remove_memory(),
> it's simply kept offline.

I have a very vague understanding of s390 specialities but this is not
really relevant to the discussion AFAICS because this happens _after_
offlining.
 
> > and the way how it does the hotremove matters here. Afterall there are
> > no arch specific operations done until the memory is offlined. Also
> > randomly checking memory blocks and then hoping that the offline will
> > succeed is not way much different from just trying the offline the
> > block. Both have to crawl through the pfn range and bail out on the
> > unmovable memory.
> 
> I think in general we have to approaches to memory unplugging.
> 
> 1. Know explicitly what you want to unplug (e.g., a DIMM spanning
> multiple memory blocks).
> 
> 2. Find random memory blocks you can offline/unplug.
> 
> 
> For 1, I think we both agree that we don't need this. Just try to
> offline and you know if it worked.
> 
> Now of course, for 2 you can try random blocks until you succeeded. From
> a sysadmin point of view that's very inefficient. From a powerpc-utils
> point of view, that's inefficient.

How exactly is check + offline more optimal then offline which makes
check as its first step? I will get to your later points after this is
clarified.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2020-01-22 18:38 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17 10:57 [PATCH RFC v1] mm: is_mem_section_removable() overhaul David Hildenbrand
2020-01-17 10:57 ` David Hildenbrand
2020-01-17 11:33 ` Michal Hocko
2020-01-17 11:33   ` Michal Hocko
2020-01-17 13:08   ` David Hildenbrand
2020-01-17 13:08     ` David Hildenbrand
2020-01-17 14:52     ` Michal Hocko
2020-01-17 14:52       ` Michal Hocko
2020-01-17 14:58       ` David Hildenbrand
2020-01-17 14:58         ` David Hildenbrand
2020-01-17 15:29         ` Michal Hocko
2020-01-17 15:29           ` Michal Hocko
2020-01-17 15:54           ` Dan Williams
2020-01-17 15:54             ` Dan Williams
2020-01-17 15:54             ` Dan Williams
2020-01-17 16:10             ` David Hildenbrand
2020-01-17 16:10               ` David Hildenbrand
2020-01-17 16:57               ` Dan Williams
2020-01-17 16:57                 ` Dan Williams
2020-01-17 16:57                 ` Dan Williams
2020-01-20  7:48                 ` Michal Hocko
2020-01-20  7:48                   ` Michal Hocko
2020-01-20  9:14                   ` David Hildenbrand
2020-01-20  9:14                     ` David Hildenbrand
2020-01-20  9:20                     ` David Hildenbrand
2020-01-20  9:20                       ` David Hildenbrand
2020-01-21 12:07                     ` Michal Hocko
2020-01-21 12:07                       ` Michal Hocko
2020-01-22 10:39                       ` David Hildenbrand
2020-01-22 10:39                         ` David Hildenbrand
2020-01-22 10:42                         ` Michal Hocko
2020-01-22 10:42                           ` Michal Hocko
2020-01-22 10:54                           ` David Hildenbrand
2020-01-22 10:54                             ` David Hildenbrand
2020-01-22 11:58                             ` David Hildenbrand
2020-01-22 11:58                               ` David Hildenbrand
2020-01-22 16:46                               ` Michal Hocko
2020-01-22 16:46                                 ` Michal Hocko
2020-01-22 18:15                                 ` David Hildenbrand
2020-01-22 18:15                                   ` David Hildenbrand
2020-01-22 18:38                                   ` Michal Hocko [this message]
2020-01-22 18:38                                     ` Michal Hocko
2020-01-22 18:46                                     ` David Hildenbrand
2020-01-22 18:46                                       ` David Hildenbrand
2020-01-22 19:09                                       ` Michal Hocko
2020-01-22 19:09                                         ` Michal Hocko
2020-01-22 20:51                                         ` Dan Williams
2020-01-22 20:51                                           ` Dan Williams
2020-01-22 20:51                                           ` Dan Williams
2020-01-22 19:01                                   ` Michal Hocko
2020-01-22 19:01                                     ` Michal Hocko

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=20200122183809.GB29276@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=allison@lohutok.net \
    --cc=anshuman.khandual@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lantianyu1986@gmail.com \
    --cc=leonardo@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathanl@linux.ibm.com \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=rafael@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    /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.