From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 425h6r12Q8zF3Ry for ; Thu, 6 Sep 2018 23:21:39 +1000 (AEST) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w86DEQDb064270 for ; Thu, 6 Sep 2018 09:21:37 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0b-001b2d01.pphosted.com with ESMTP id 2mb3cn4ts3-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 06 Sep 2018 09:21:36 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 6 Sep 2018 14:21:35 +0100 Date: Thu, 6 Sep 2018 16:21:26 +0300 From: Mike Rapoport To: Pasha Tatashin Cc: Michal Hocko , "linux-mm@kvack.org" , Andrew Morton , "David S. Miller" , Greg Kroah-Hartman , Ingo Molnar , Michael Ellerman , Paul Burton , Thomas Gleixner , Tony Luck , "linux-ia64@vger.kernel.org" , "linux-mips@linux-mips.org" , "linuxppc-dev@lists.ozlabs.org" , "sparclinux@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 00/29] mm: remove bootmem allocator References: <1536163184-26356-1-git-send-email-rppt@linux.vnet.ibm.com> <20180906091538.GN14951@dhcp22.suse.cz> <46ae5e64-7b1a-afab-bfef-d00183a7ef76@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <46ae5e64-7b1a-afab-bfef-d00183a7ef76@microsoft.com> Message-Id: <20180906132126.GK27492@rapoport-lnx> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Sep 06, 2018 at 01:04:47PM +0000, Pasha Tatashin wrote: > > > On 9/6/18 5:15 AM, Michal Hocko wrote: > > On Wed 05-09-18 18:59:15, Mike Rapoport wrote: > > [...] > >> 325 files changed, 846 insertions(+), 2478 deletions(-) > >> delete mode 100644 include/linux/bootmem.h > >> delete mode 100644 mm/bootmem.c > >> delete mode 100644 mm/nobootmem.c > > > > This is really impressive! Thanks a lot for working on this. I wish we > > could simplify the memblock API as well. There are just too many public > > functions with subtly different semantic and barely any useful > > documentation. > > > > But even this is a great step forward! > > This is a great simplification of boot process. Thank you Mike! > > I agree, with Michal in the future, once nobootmem kernel stabalizes > after this effort, we should start simplifying memblock allocator API: > it won't be as big effort as this one, as I think, that can be done in > incremental phases, but it will help to make early boot much more stable > and uniform across arches. It's not only about the memblock APIs. Every arch has its own way of memory detection and initialization, all this should be revisited at some point. But yes, apart from the memblock APIs update which will be quite disruptive, the arches memory initialization can be updated incrementally. > Thank you, > Pavel -- Sincerely yours, Mike.