Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5539923imm; Wed, 12 Sep 2018 07:29:30 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda7EshwDLdFMJbE3jGbBTrRQPmVh7UOzF5y5wySxZm4N1SgslznRjLGiNn9TpVjOo+esUVC X-Received: by 2002:a62:63c2:: with SMTP id x185-v6mr2681972pfb.13.1536762570028; Wed, 12 Sep 2018 07:29:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536762570; cv=none; d=google.com; s=arc-20160816; b=ERQr8ACRdcccuxNq7d99WAgSMTq7rb22CjfFOsXovGVTBrd4dFjb99IFca11C1JyaX 203dKNCMxd+x1nTLNEWQG3/DwoZu8g/fsSkRzNaIiaQpXoGJHioHeXAJQVGOG0/MP8e2 o8b0DJ1UPKcl6datBwy4xhyuJ8KNfWL9GAS8IIBJ5wnKJCEGuVDKkraftLrCAs0AspWb W9XOD+VqfHfY6LrWVMSr6xdvrhl00c46wB3gUpG8eRZqvzMdxHBdSf1EK24oSf+jHI2i opzx1cLivb7hAzb5rzziWN18H9mYk9WgAcG6RTn4+gE6ZsS5uU85fhyd3tM3FQ6rtxd9 cmIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:message-id :mime-version:references:in-reply-to:subject:cc:to:from:date; bh=CkCTtJJkPfQWsPAbJeFOk4v8Q5Wroel8U/GiVUMf/mE=; b=i0ER2IDfKwhG/Mp2PMHnv2o3LuMR/zQr6+ZGnyPKtD3EX9nfBYp9h57onwvKJiSdE4 aBdIpP3PgLWZ/Cpw57C8dlyoGgdZRE1HnDQ9nvaSqiaC5irVV2Fu9Emqx57+eqlK4wt4 P3C2CtqWIT2Lv3Ep34r7lr4Vo6YffB6UaOkrKl5VRs69n/VE0mAxn/3Q7pkc8uvNSmDp Be7Hk7lL5bvTY1UxA8u64h3J+g2ba1on2JZINTB1mDeL9RWjltdOL4uqi2ZCH+NAePNg esYTVME1FZe58zug4p5qn4JyZEPx0eJ2mn7JsuA25efJorPlHSYr15ZeAeEm2C3kZ66F IExQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o7-v6si1125769pfk.356.2018.09.12.07.29.14; Wed, 12 Sep 2018 07:29:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727161AbeILTdu (ORCPT + 99 others); Wed, 12 Sep 2018 15:33:50 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:35562 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726672AbeILTdt (ORCPT ); Wed, 12 Sep 2018 15:33:49 -0400 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8CEOHPP136829 for ; Wed, 12 Sep 2018 10:29:03 -0400 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 2mf3fu3nw9-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 12 Sep 2018 10:29:03 -0400 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 12 Sep 2018 15:29:01 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp03.uk.ibm.com (192.168.101.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 12 Sep 2018 15:28:59 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w8CESwFX55509200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 12 Sep 2018 14:28:58 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0BEFD5204F; Wed, 12 Sep 2018 17:28:47 +0100 (BST) Received: from thinkpad (unknown [9.152.212.168]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id C52875204E; Wed, 12 Sep 2018 17:28:46 +0100 (BST) Date: Wed, 12 Sep 2018 16:28:56 +0200 From: Gerald Schaefer To: Pasha Tatashin Cc: Michal Hocko , "zaslonko@linux.ibm.com" , Andrew Morton , LKML , Linux Memory Management List , "osalvador@suse.de" Subject: Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary In-Reply-To: References: <20180910123527.71209-1-zaslonko@linux.ibm.com> <20180910131754.GG10951@dhcp22.suse.cz> <20180910135959.GI10951@dhcp22.suse.cz> <20180910141946.GJ10951@dhcp22.suse.cz> <20180910144152.GL10951@dhcp22.suse.cz> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 18091214-0012-0000-0000-000002A7C2EC X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18091214-0013-0000-0000-000020DC0532 Message-Id: <20180912162856.697038a8@thinkpad> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-12_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=752 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809120149 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 10 Sep 2018 15:26:55 +0000 Pasha Tatashin wrote: > > I agree memoryblock is a hack, it fails to do both things it was > designed to do: > > 1. On bare metal you cannot free a physical dimm of memory using > memoryblock granularity because memory devices do not equal to physical > dimms. Thus, if for some reason a particular dimm must be > remove/replaced, memoryblock does not help us. > > 2. On machines with hypervisors it fails to provide an adequate > granularity to add/remove memory. > > We should define a new user interface where memory can be added/removed > at a finer granularity: sparse section size, but without a memory > devices for each section. We should also provide an optional access to > legacy interface where memory devices are exported but each is of > section size. > > So, when legacy interface is enabled, current way would work: > > echo offline > /sys/devices/system/memory/memoryXXX/state > > And new interface would allow us to do something like this: > > echo offline 256M > /sys/devices/system/node/nodeXXX/memory > > With optional start address for offline memory. > echo offline [start_pa] size > /sys/devices/system/node/nodeXXX/memory > start_pa and size must be section size aligned (128M). > > It would probably be a good discussion for the next MM Summit how to > solve the current memory hotplug interface limitations. Please keep lsmem/chmem from util-linux in mind, when changing the memory hotplug user interface.