From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753927AbdLDMmo (ORCPT ); Mon, 4 Dec 2017 07:42:44 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:35774 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752691AbdLDMml (ORCPT ); Mon, 4 Dec 2017 07:42:41 -0500 Date: Mon, 4 Dec 2017 12:42:31 +0000 From: Andrea Reale To: Michal Hocko Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, m.bielski@virtualopensystems.com, arunks@qti.qualcomm.com, mark.rutland@arm.com, scott.branden@broadcom.com, will.deacon@arm.com, qiuxishi@huawei.com, catalin.marinas@arm.com, realean2@ie.ibm.com Subject: Re: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem References: <20171130145134.el3qq7pr3q4xqglz@dhcp22.suse.cz> <20171204114908.GC6373@samekh> <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 17120412-0040-0000-0000-000003F626D7 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120412-0041-0000-0000-000025F91774 Message-Id: <20171204124230.GA10599@samekh> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-04_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712040184 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 4 Dec 2017, 13:32, Michal Hocko wrote: > On Mon 04-12-17 11:49:09, Andrea Reale wrote: > > On Thu 30 Nov 2017, 15:51, Michal Hocko wrote: > > > On Thu 23-11-17 11:14:38, Andrea Reale wrote: > > > > When hot-removing memory we need to free vmemmap memory. > > > > However, depending on the memory is being removed, it might > > > > not be always possible to free a full vmemmap page / huge-page > > > > because part of it might still be used. > > > > > > > > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables > > > > hot-remove") introduced a workaround for x86 > > > > hot-remove, by which partially unused areas are filled with > > > > the 0xFD constant. Full pages are only removed when fully > > > > filled by 0xFDs. > > > > > > > > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with > > > > the goal of using it in place of 0xFDs. For now, this will be used for > > > > the arm64 port of memory hot remove, but the idea is to eventually use > > > > the same mechanism for x86 as well. > > > > > > Why cannot you use the same approach as x86 have? Have a look at the > > > vmemmap_free at al. > > > > > > > This arm64 hot-remove version (including vmemmap_free) is indeed an > > almost 1-to-1 port of the x86 approach. > > > > If you look at the first version of the patchset we submitted a while > > ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the > > x86 approach of filling unsued page structs with 0xFDs. Commenting on > > that, Mark suggested (and, indeed, I agree with him) that relying on a > > magic constant for marking some portions of physical memory was quite > > ugly. That is why we have used memblock for the purpose in this revised > > patchset. > > > > If you have a different view and any concrete suggestion on how to > > improve this, it is definitely very well welcome. > > I would really prefer if those archictectues shared the code (and > concept) as much as possible. It is really a PITA to wrap your head > around each architectures for reasons which are not inherent to that > specific architecture. If you find the way how x86 is implemented ugly, > then all right, but making arm64 special just for the matter of taste is > far from ideal IMHO. The plan is indeed to use this memblock flag in x86 hot remove as well, in place of the 0xFDs. The change is quite straightforward and we could push it in a next patchset release. Our rationale was to first use it in the new architecture and then, once proven stable, back port it to x86. However, I am not in principle against of pushing it right now. Thanks, Andrea > -- > Michal Hocko > SUSE Labs > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f200.google.com (mail-wr0-f200.google.com [209.85.128.200]) by kanga.kvack.org (Postfix) with ESMTP id CD13C6B028F for ; Mon, 4 Dec 2017 07:42:42 -0500 (EST) Received: by mail-wr0-f200.google.com with SMTP id t92so10242602wrc.13 for ; Mon, 04 Dec 2017 04:42:42 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com. [148.163.158.5]) by mx.google.com with ESMTPS id z1si1354681eda.372.2017.12.04.04.42.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Dec 2017 04:42:41 -0800 (PST) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB4Cdt9u021985 for ; Mon, 4 Dec 2017 07:42:40 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2en59rc68e-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 04 Dec 2017 07:42:39 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 4 Dec 2017 12:42:37 -0000 Date: Mon, 4 Dec 2017 12:42:31 +0000 From: Andrea Reale Subject: Re: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem References: <20171130145134.el3qq7pr3q4xqglz@dhcp22.suse.cz> <20171204114908.GC6373@samekh> <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz> Message-Id: <20171204124230.GA10599@samekh> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, m.bielski@virtualopensystems.com, arunks@qti.qualcomm.com, mark.rutland@arm.com, scott.branden@broadcom.com, will.deacon@arm.com, qiuxishi@huawei.com, catalin.marinas@arm.com, realean2@ie.ibm.com On Mon 4 Dec 2017, 13:32, Michal Hocko wrote: > On Mon 04-12-17 11:49:09, Andrea Reale wrote: > > On Thu 30 Nov 2017, 15:51, Michal Hocko wrote: > > > On Thu 23-11-17 11:14:38, Andrea Reale wrote: > > > > When hot-removing memory we need to free vmemmap memory. > > > > However, depending on the memory is being removed, it might > > > > not be always possible to free a full vmemmap page / huge-page > > > > because part of it might still be used. > > > > > > > > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables > > > > hot-remove") introduced a workaround for x86 > > > > hot-remove, by which partially unused areas are filled with > > > > the 0xFD constant. Full pages are only removed when fully > > > > filled by 0xFDs. > > > > > > > > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with > > > > the goal of using it in place of 0xFDs. For now, this will be used for > > > > the arm64 port of memory hot remove, but the idea is to eventually use > > > > the same mechanism for x86 as well. > > > > > > Why cannot you use the same approach as x86 have? Have a look at the > > > vmemmap_free at al. > > > > > > > This arm64 hot-remove version (including vmemmap_free) is indeed an > > almost 1-to-1 port of the x86 approach. > > > > If you look at the first version of the patchset we submitted a while > > ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the > > x86 approach of filling unsued page structs with 0xFDs. Commenting on > > that, Mark suggested (and, indeed, I agree with him) that relying on a > > magic constant for marking some portions of physical memory was quite > > ugly. That is why we have used memblock for the purpose in this revised > > patchset. > > > > If you have a different view and any concrete suggestion on how to > > improve this, it is definitely very well welcome. > > I would really prefer if those archictectues shared the code (and > concept) as much as possible. It is really a PITA to wrap your head > around each architectures for reasons which are not inherent to that > specific architecture. If you find the way how x86 is implemented ugly, > then all right, but making arm64 special just for the matter of taste is > far from ideal IMHO. The plan is indeed to use this memblock flag in x86 hot remove as well, in place of the 0xFDs. The change is quite straightforward and we could push it in a next patchset release. Our rationale was to first use it in the new architecture and then, once proven stable, back port it to x86. However, I am not in principle against of pushing it right now. Thanks, Andrea > -- > Michal Hocko > SUSE Labs > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: ar@linux.vnet.ibm.com (Andrea Reale) Date: Mon, 4 Dec 2017 12:42:31 +0000 Subject: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem In-Reply-To: <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz> References: <20171130145134.el3qq7pr3q4xqglz@dhcp22.suse.cz> <20171204114908.GC6373@samekh> <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz> Message-ID: <20171204124230.GA10599@samekh> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon 4 Dec 2017, 13:32, Michal Hocko wrote: > On Mon 04-12-17 11:49:09, Andrea Reale wrote: > > On Thu 30 Nov 2017, 15:51, Michal Hocko wrote: > > > On Thu 23-11-17 11:14:38, Andrea Reale wrote: > > > > When hot-removing memory we need to free vmemmap memory. > > > > However, depending on the memory is being removed, it might > > > > not be always possible to free a full vmemmap page / huge-page > > > > because part of it might still be used. > > > > > > > > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables > > > > hot-remove") introduced a workaround for x86 > > > > hot-remove, by which partially unused areas are filled with > > > > the 0xFD constant. Full pages are only removed when fully > > > > filled by 0xFDs. > > > > > > > > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with > > > > the goal of using it in place of 0xFDs. For now, this will be used for > > > > the arm64 port of memory hot remove, but the idea is to eventually use > > > > the same mechanism for x86 as well. > > > > > > Why cannot you use the same approach as x86 have? Have a look at the > > > vmemmap_free at al. > > > > > > > This arm64 hot-remove version (including vmemmap_free) is indeed an > > almost 1-to-1 port of the x86 approach. > > > > If you look at the first version of the patchset we submitted a while > > ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the > > x86 approach of filling unsued page structs with 0xFDs. Commenting on > > that, Mark suggested (and, indeed, I agree with him) that relying on a > > magic constant for marking some portions of physical memory was quite > > ugly. That is why we have used memblock for the purpose in this revised > > patchset. > > > > If you have a different view and any concrete suggestion on how to > > improve this, it is definitely very well welcome. > > I would really prefer if those archictectues shared the code (and > concept) as much as possible. It is really a PITA to wrap your head > around each architectures for reasons which are not inherent to that > specific architecture. If you find the way how x86 is implemented ugly, > then all right, but making arm64 special just for the matter of taste is > far from ideal IMHO. The plan is indeed to use this memblock flag in x86 hot remove as well, in place of the 0xFDs. The change is quite straightforward and we could push it in a next patchset release. Our rationale was to first use it in the new architecture and then, once proven stable, back port it to x86. However, I am not in principle against of pushing it right now. Thanks, Andrea > -- > Michal Hocko > SUSE Labs >