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
next prev parent 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: linkBe 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.