From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Date: Wed, 3 Oct 2018 19:06:28 +0200 Message-ID: <37fab0d1-4b5d-ff69-9091-2f9e34b47e4e@redhat.com> References: <20180928150357.12942-1-david@redhat.com> <20181001084038.GD18290@dhcp22.suse.cz> <20181002134734.GT18290@dhcp22.suse.cz> <98fb8d65-b641-2225-f842-8804c6f79a06@redhat.com> <8736tndubn.fsf@vitty.brq.redhat.com> <20181003134444.GH4714@dhcp22.suse.cz> <87zhvvcf3b.fsf@vitty.brq.redhat.com> <20181003142444.GJ4714@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181003142444.GJ4714@dhcp22.suse.cz> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Michal Hocko , Vitaly Kuznetsov Cc: Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Benjamin Herrenschmidt , Balbir Singh , Dave Hansen , Heiko Carstens , linux-mm@kvack.org, Paul Mackerras , "H. Peter Anvin" , Stephen Rothwell , Rashmica Gupta , Dan Williams , linux-s390@vger.kernel.org, Michael Neuling , Stephen Hemminger , Yoshinori Sato , Michael Ellerman , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Len Brown , Pavel List-Id: linux-acpi@vger.kernel.org On 03/10/2018 16:24, Michal Hocko wrote: > On Wed 03-10-18 15:52:24, Vitaly Kuznetsov wrote: > [...] >>> As David said some of the memory cannot be onlined without further steps >>> (e.g. when it is standby as David called it) and then I fail to see how >>> eBPF help in any way. >> >> and also, we can fight till the end of days here trying to come up with >> an onlining solution which would work for everyone and eBPF would move >> this decision to distro level. > > The point is that there is _no_ general onlining solution. This is > basically policy which belongs to the userspace. > As already stated, I guess we should then provide user space with sufficient information to make a good decision (to implement rules). The eBPF is basically the same idea, only the rules are formulated differently and directly handle in the kernel. Still it might be e.e. relevant if memory is standby memory (that's what I remember the official s390x name), or something else. Right now, the (udev) rules we have make assumptions based on general system properties (s390x, HyperV ...). -- Thanks, David / dhildenb