From: Michal Hocko <mhocko@kernel.org> To: David Hildenbrand <david@redhat.com> Cc: linux-kernel@vger.kernel.org, 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>, Dan Williams <dan.j.williams@intel.com>, Stephen Rothwell <sfr@canb.auug.org.au>, Anshuman Khandual <anshuman.khandual@arm.com>, lantianyu1986@gmail.com, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul Date: Fri, 17 Jan 2020 16:29:47 +0100 [thread overview] Message-ID: <20200117152947.GK19428@dhcp22.suse.cz> (raw) In-Reply-To: <65606e2e-1cf7-de3b-10b1-33653cb41a52@redhat.com> On Fri 17-01-20 15:58:26, David Hildenbrand wrote: > On 17.01.20 15:52, Michal Hocko wrote: > > On Fri 17-01-20 14:08:06, David Hildenbrand wrote: > >> On 17.01.20 12:33, Michal Hocko wrote: > >>> On Fri 17-01-20 11:57:59, David Hildenbrand wrote: > >>>> Let's refactor that code. We want to check if we can offline memory > >>>> blocks. Add a new function is_mem_section_offlineable() for that and > >>>> make it call is_mem_section_offlineable() for each contained section. > >>>> Within is_mem_section_offlineable(), add some more sanity checks and > >>>> directly bail out if the section contains holes or if it spans multiple > >>>> zones. > >>> > >>> I didn't read the patch (yet) but I am wondering. If we want to touch > >>> this code, can we simply always return true there? I mean whoever > >>> depends on this check is racy and the failure can happen even after > >>> the sysfs says good to go, right? The check is essentially as expensive > >>> as calling the offlining code itself. So the only usecase I can think of > >>> is a dumb driver to crawl over blocks and check which is removable and > >>> try to hotremove it. But just trying to offline one block after another > >>> is essentially going to achieve the same. > >> > >> Some thoughts: > >> > >> 1. It allows you to check if memory is likely to be offlineable without > >> doing expensive locking and trying to isolate pages (meaning: > >> zone->lock, mem_hotplug_lock. but also, calling drain_all_pages() > >> when isolating) > >> > >> 2. There are use cases that want to identify a memory block/DIMM to > >> unplug. One example is PPC DLPAR code (see this patch). Going over all > >> memory block trying to offline them is an expensive operation. > >> > >> 3. powerpc-utils (https://github.com/ibm-power-utilities/powerpc-utils) > >> makes use of /sys/.../removable to speed up the search AFAIK. > > > > Well, while I do see those points I am not really sure they are worth > > having a broken (by-definition) interface. > > It's a pure speedup. And for that, the interface has been working > perfectly fine for years? > > > > >> 4. lsmem displays/groups by "removable". > > > > Is anybody really using that? > > Well at least I am using that when testing to identify which > (ZONE_NORMAL!) block I can easily offline/re-online (e.g., to validate > all the zone shrinking stuff I have been fixing) > > So there is at least one user ;) Fair enough. But I would argue that there are better ways to do the same solely for testing purposes. Rather than having a subtly broken code to maintain. > > > >>> Or does anybody see any reasonable usecase that would break if we did > >>> that unconditional behavior? > >> > >> If we would return always "true", then the whole reason the > >> interface originally was introduced would be "broken" (meaning, less > >> performant as you would try to offline any memory block). > > > > I would argue that the whole interface is broken ;). Not the first time > > in the kernel development history and not the last time either. What I > > am trying to say here is that unless there are _real_ usecases depending > > on knowing that something surely is _not_ offlineable then I would just > > try to drop the functionality while preserving the interface and see > > what happens. > > I can see that, but I can perfectly well understand why - especially > powerpc - wants a fast way to sense which blocks actually sense to try > to online. > > The original patch correctly states > "which sections of > memory are likely to be removable before attempting the potentially > expensive operation." > > It works as designed I would say. Then I would just keep it crippled the same way it has been for years without anybody noticing. -- 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>, "Rafael J. Wysocki" <rafael@kernel.org>, Anshuman Khandual <anshuman.khandual@arm.com>, Dan Williams <dan.j.williams@intel.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Leonardo Bras <leonardo@linux.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org, Nathan Fontenot <nfont@linux.vnet.ibm.com>, Allison Randal <allison@lohutok.net>, lantianyu1986@gmail.com Subject: Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul Date: Fri, 17 Jan 2020 16:29:47 +0100 [thread overview] Message-ID: <20200117152947.GK19428@dhcp22.suse.cz> (raw) In-Reply-To: <65606e2e-1cf7-de3b-10b1-33653cb41a52@redhat.com> On Fri 17-01-20 15:58:26, David Hildenbrand wrote: > On 17.01.20 15:52, Michal Hocko wrote: > > On Fri 17-01-20 14:08:06, David Hildenbrand wrote: > >> On 17.01.20 12:33, Michal Hocko wrote: > >>> On Fri 17-01-20 11:57:59, David Hildenbrand wrote: > >>>> Let's refactor that code. We want to check if we can offline memory > >>>> blocks. Add a new function is_mem_section_offlineable() for that and > >>>> make it call is_mem_section_offlineable() for each contained section. > >>>> Within is_mem_section_offlineable(), add some more sanity checks and > >>>> directly bail out if the section contains holes or if it spans multiple > >>>> zones. > >>> > >>> I didn't read the patch (yet) but I am wondering. If we want to touch > >>> this code, can we simply always return true there? I mean whoever > >>> depends on this check is racy and the failure can happen even after > >>> the sysfs says good to go, right? The check is essentially as expensive > >>> as calling the offlining code itself. So the only usecase I can think of > >>> is a dumb driver to crawl over blocks and check which is removable and > >>> try to hotremove it. But just trying to offline one block after another > >>> is essentially going to achieve the same. > >> > >> Some thoughts: > >> > >> 1. It allows you to check if memory is likely to be offlineable without > >> doing expensive locking and trying to isolate pages (meaning: > >> zone->lock, mem_hotplug_lock. but also, calling drain_all_pages() > >> when isolating) > >> > >> 2. There are use cases that want to identify a memory block/DIMM to > >> unplug. One example is PPC DLPAR code (see this patch). Going over all > >> memory block trying to offline them is an expensive operation. > >> > >> 3. powerpc-utils (https://github.com/ibm-power-utilities/powerpc-utils) > >> makes use of /sys/.../removable to speed up the search AFAIK. > > > > Well, while I do see those points I am not really sure they are worth > > having a broken (by-definition) interface. > > It's a pure speedup. And for that, the interface has been working > perfectly fine for years? > > > > >> 4. lsmem displays/groups by "removable". > > > > Is anybody really using that? > > Well at least I am using that when testing to identify which > (ZONE_NORMAL!) block I can easily offline/re-online (e.g., to validate > all the zone shrinking stuff I have been fixing) > > So there is at least one user ;) Fair enough. But I would argue that there are better ways to do the same solely for testing purposes. Rather than having a subtly broken code to maintain. > > > >>> Or does anybody see any reasonable usecase that would break if we did > >>> that unconditional behavior? > >> > >> If we would return always "true", then the whole reason the > >> interface originally was introduced would be "broken" (meaning, less > >> performant as you would try to offline any memory block). > > > > I would argue that the whole interface is broken ;). Not the first time > > in the kernel development history and not the last time either. What I > > am trying to say here is that unless there are _real_ usecases depending > > on knowing that something surely is _not_ offlineable then I would just > > try to drop the functionality while preserving the interface and see > > what happens. > > I can see that, but I can perfectly well understand why - especially > powerpc - wants a fast way to sense which blocks actually sense to try > to online. > > The original patch correctly states > "which sections of > memory are likely to be removable before attempting the potentially > expensive operation." > > It works as designed I would say. Then I would just keep it crippled the same way it has been for years without anybody noticing. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2020-01-17 15:29 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 [this message] 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 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=20200117152947.GK19428@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.