From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types Date: Mon, 26 Nov 2018 15:20:15 +0100 Message-ID: <20181126152015.7464c786@naga> 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: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" 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" , Rashmica Gupta , Boris Ostrovsky , Stephen Rothwell , Michael Neuling , Stephen Hemminger , Yoshinori Sato , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Rob Herring , Len Brown , Pavel Tatashin , linux-s390@vger.kernel.org"mike.travis@hpe.com" List-Id: linux-acpi@vger.kernel.org T24gTW9uLCAyNiBOb3YgMjAxOCAxNDozMzoyOSArMDEwMApEYXZpZCBIaWxkZW5icmFuZCA8ZGF2 aWRAcmVkaGF0LmNvbT4gd3JvdGU6Cgo+IE9uIDI2LjExLjE4IDEzOjMwLCBEYXZpZCBIaWxkZW5i cmFuZCB3cm90ZToKPiA+IE9uIDIzLjExLjE4IDE5OjA2LCBNaWNoYWwgU3VjaMOhbmVrIHdyb3Rl OiAgCgo+ID4+Cj4gPj4gSWYgd2UgYXJlIGdvaW5nIHRvIGZha2UgdGhlIGRyaXZlciBpbmZvcm1h dGlvbiB3ZSBtYXkgYXMgd2VsbCBhZGQgdGhlCj4gPj4gdHlwZSBhdHRyaWJ1dGUgYW5kIGJlIGRv bmUgd2l0aCBpdC4KPiA+Pgo+ID4+IEkgdGhpbmsgdGhlIHByb2JsZW0gd2l0aCB0aGUgcGF0Y2gg d2FzIG1vcmUgd2l0aCB0aGUgc2VtYW50aWMgdGhhbiB0aGUKPiA+PiBhdHRyaWJ1dGUgaXRzZWxm Lgo+ID4+Cj4gPj4gV2hhdCBpcyBub3JtYWwsIHBhcmF2aXJ0dWFsaXplZCwgYW5kIHN0YW5kYnkg bWVtb3J5Pwo+ID4+Cj4gPj4gSSBjYW4gdW5kZXJzdGFuZCBESU1NIGRldmljZSwgYmFsb29uIGRl dmljZSwgb3Igd2hhdGV2ZXIgbWVjaGFuaXNtIGZvcgo+ID4+IGFkZGluZyBtZW1vcnkgeW91IG1p Z2h0IGhhdmUuCj4gPj4KPiA+PiBJIGNhbiB1bmRlcnN0YW5kICJtZW1vcnkgZGVzaWduYXRlZCBh cyBzdGFuZGJ5IGJ5IHRoZSBjbHVzdGVyCj4gPj4gYWRtaW5pc3RyYXRvciIuCj4gPj4KPiA+PiBI b3dldmVyLCBESU1NIHZzIGJhbG9vbiBpcyBvcnRob2dvbmFsIHRvIHN0YW5kYnkgYW5kIHNob3Vs ZCBub3QgYmUKPiA+PiBjb25mbGF0ZWQgaW50byBvbmUgcHJvcGVydHkuCj4gPj4KPiA+PiBwYXJh dmlydHVhbGl6ZWQgbWVhbnMgbm90aGluZyBhdCBhbGwgaW4gcmVsYXRpb25zaGlwIHRvIG1lbW9y eSB0eXBlIGFuZAo+ID4+IHRoZSBkZXNpcmVkIG9ubGluZSBwb2xpY3kgdG8gbWUuICAKPiA+IAo+ ID4gUmlnaHQsIHNvIHdpdGggd2hhdGV2ZXIgd2UgY29tZSB1cCwgaXQgc2hvdWxkIGFsbG93IHRv IG1ha2UgYSBkZWNpc2lvbgo+ID4gaW4gdXNlciBzcGFjZSBhYm91dAo+ID4gLSBpZiBtZW1vcnkg aXMgdG8gYmUgb25saW5lZCBhdXRvbWF0aWNhbGx5ICAKPiAKPiBBbmQgSSB3aWxsIHRoaW5rIGFi b3V0IGlmIHdlIHJlYWxseSBzaG91bGQgbW9kZWwgc3RhbmRieSBtZW1vcnkuIE1heWJlCj4gaXQg aXMgcmVhbGx5IGJldHRlciB0byBoYXZlIGluIHVzZXIgc3BhY2Ugc29tZXRoaW5nIGxpa2UgKGFz IERhbiBub3RlZCkKCklmIGl0IGlzIHBvc3NpYmxlIHRvIGRlc2lnbmF0ZSB0aGUgbWVtb3J5IGFz IHN0YW5kYnkgb3Igb25saW5lIGluIHRoZQpzMzkwIGFkbWluIGludGVyZmFjZSBhbmQgdGhlIGtl cm5lbCBkb2VzIGhhdmUgYWNjZXNzIHRvIHRoaXMKaW5mb3JtYXRpb24gaXQgbWFrZXMgc2Vuc2Ug dG8gZm9yd2FyZCBpdCB0byB1c2Vyc3BhY2UgKGFzIHNlcGFyYXRlCnMzOTAtc3BlY2lmaWMgcHJv cGVydHkpLiBJZiBub3QgdGhlbiB5b3UgbmVlZCB0byBtYWtlIHNvbWUga2luZCBvZgphc3N1bXB0 aW9uIGxpa2UgYmVsb3cgYW5kIHRoZSB1c2VyIGNhbiB0dW5lIHRoZSBzY3JpcHQgYWNjb3JkaW5n IHRvCnRoZWlyIHVzZWNhc2UuCgo+IAo+IGlmIChpc1MzOTB4KCkgJiYgdHlwZSA9PSAiZGltbSIp IHsKPiAJLyogZG9uJ3Qgb25saW5lLCBvbiBzMzkweCBzeXN0ZW0gRElNTXMgYXJlIHN0YW5kYnkg bWVtb3J5ICovCj4gfQoKVGhhbmtzCgpNaWNoYWwKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KZGV2ZWwgbWFpbGluZyBsaXN0CmRldmVsQGxpbnV4ZHJpdmVy cHJvamVjdC5vcmcKaHR0cDovL2RyaXZlcmRldi5saW51eGRyaXZlcnByb2plY3Qub3JnL21haWxt YW4vbGlzdGluZm8vZHJpdmVyZGV2LWRldmVsCg== 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC17DC43441 for ; Mon, 26 Nov 2018 14:22:44 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2F6E920855 for ; Mon, 26 Nov 2018 14:22:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F6E920855 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 433Tdt1VpmzDqHH for ; Tue, 27 Nov 2018 01:22:42 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=suse.de (client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=msuchanek@suse.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.de Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 433TbH3mj5zDqNS for ; Tue, 27 Nov 2018 01:20:26 +1100 (AEDT) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id C7B4FB02B; Mon, 26 Nov 2018 14:20:22 +0000 (UTC) Date: Mon, 26 Nov 2018 15:20:15 +0100 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= To: David Hildenbrand 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>

X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" , Rashmica Gupta , "K. Y. Srinivasan" , Boris Ostrovsky , Stephen Rothwell , Michael Neuling , Stephen Hemminger , Yoshinori Sato , linux-acpi@vger.kernel.org, Ingo Molnar , xen-devel@lists.xenproject.org, Rob Herring , Len Brown , Pavel Tatashin , linux-s390@vger.kernel.org, "mike.travis@hpe.com" , Haiyang Zhang , Jonathan =?UTF-8?B?TmV1c2Now6Rm?= =?UTF-8?B?ZXI=?= , Nicholas Piggin , Joe Perches , =?UTF-8?B?SsOpcsO0bWU=?= Glisse , Mike Rapoport , Borislav Petkov , Andy Lutomirski , Dan Williams , Joonsoo Kim , 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 , Martin Schwidefsky , devel@linuxdriverproject.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, "Kirill A. Shutemov" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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