From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by kanga.kvack.org (Postfix) with ESMTP id 698A36B421E for ; Mon, 26 Nov 2018 09:20:26 -0500 (EST) Received: by mail-ed1-f71.google.com with SMTP id b3so1639171edi.0 for ; Mon, 26 Nov 2018 06:20:26 -0800 (PST) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id t44si437774eda.120.2018.11.26.06.20.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 06:20:24 -0800 (PST) Date: Mon, 26 Nov 2018 15:20:15 +0100 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Message-ID: <20181126152015.7464c786@naga> In-Reply-To: References: <20180928150357.12942-1-david@redhat.com> <20181123190653.6da91461@kitsune.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: David Hildenbrand Cc: Kate Stewart , Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Dave Hansen , Heiko Carstens , linux-mm@kvack.org, Michal Hocko , Paul Mackerras , "H. Peter Anvin" , Stephen Rothwell , Rashmica Gupta , "K. Y." Srinivasan" , Dan Williams ," linux-s390@vger.kernel.org, Michael Neuling , Stephen Hemminger , Yoshinori Sato , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Len Brown , Pavel Tatashin , Rob Herring , "mike.travis@hpe.com" , Haiyang Zhang , Jonathan =?UTF-8?B?TmV1c2Now6Rm?= =?UTF-8?B?ZXI=?= , Nicholas Piggin , Martin Schwidefsky , =?UTF-8?B?SsOpcsO0bWU=?= Glisse , Mike Rapoport , Borislav Petkov , Andy Lutomirski , Boris Ostrovsky , Andrew Morton , Oscar Salvador , Juergen Gross , Tony Luck , Mathieu Malaterre , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Fenghua Yu , Mauricio Faria de Oliveira , Thomas Gleixner , Philippe Ombredanne , Joe Perches , devel@linuxdriverproject.org, Joonsoo Kim , linuxppc-dev@lists.ozlabs.org, Kirill A. On Mon, 26 Nov 2018 14:33:29 +0100 David Hildenbrand wrote: > On 26.11.18 13:30, David Hildenbrand wrote: > > On 23.11.18 19:06, Michal Such=C3=A1nek wrote: =20 > >> > >> If we are going to fake the driver information we may as well add the > >> type attribute and be done with it. > >> > >> I think the problem with the patch was more with the semantic than the > >> attribute itself. > >> > >> What is normal, paravirtualized, and standby memory? > >> > >> I can understand DIMM device, baloon device, or whatever mechanism for > >> adding memory you might have. > >> > >> I can understand "memory designated as standby by the cluster > >> administrator". > >> > >> However, DIMM vs baloon is orthogonal to standby and should not be > >> conflated into one property. > >> > >> paravirtualized means nothing at all in relationship to memory type and > >> the desired online policy to me. =20 > >=20 > > Right, so with whatever we come up, it should allow to make a decision > > in user space about > > - if memory is to be onlined automatically =20 >=20 > And I will think about if we really should model standby memory. Maybe > it is really better to have in user space something like (as Dan noted) If it is possible to designate the memory as standby or online in the s390 admin interface and the kernel does have access to this information it makes sense to forward it to userspace (as separate s390-specific property). If not then you need to make some kind of assumption like below and the user can tune the script according to their usecase. >=20 > if (isS390x() && type =3D=3D "dimm") { > /* don't online, on s390x system DIMMs are standby memory */ > } Thanks Michal