Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1379384imm; Thu, 12 Jul 2018 00:27:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeWaHYBC7g5uQGD2S+xI4i2Yi/7awpxB2xvac5rs4jV37CSgwlKSRXpLwyppKvpvYv83/sC X-Received: by 2002:a62:9d14:: with SMTP id i20-v6mr1171093pfd.3.1531380433320; Thu, 12 Jul 2018 00:27:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531380433; cv=none; d=google.com; s=arc-20160816; b=h9dE8rN+LGVqFATF3QEGxr2Ey2BLP7aySbC78e0NMhdDHOBVYOXWhOlcdgKXmDsMJQ cFJeXlNcb73C4zezVcIgvoWUscRSP7qBGP5Ye0rE84BR6BKfenBO9k1v1QiaHJtOduaK NrNOsVmnQ3mGw3f8U+hueyjiTHYBmrFN34mTHpZQwosUSBtnQcAWMDzX2/Zcp9jjdj/Z 1EvDXZw/cw57BuPXvWcMl55k4gGRTzm81pEg2W7NQhhDntjsrbwp4zlYyK6lyHFxbPl6 EBEByeiC5x71T1v7+CSqngUSlApDKMVlZNslN3pPPpOG+91tK+Rz2J3Q9ShuZEet3eEA Dt3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:subject:cc:to:from:date :arc-authentication-results; bh=Go7td/NwqY6rvYLoVOUtIH7/VSg6pJSTGVLwO9Fb2E8=; b=tNqXM5cvHUF/+6Ui/lXHtg9fXCJdKbietQ1XTkN13yyeDm6pDEKztckEetgD0zJDjP f4EwJpHKhAfGbo8rosAlsSDN3ju+orifmG1r1fhngR2wnqRUReP1l50PnCYJfLRI0Uec JB/JI37nKLkQKbTekSjGjARgsUMlRdD/hfeorRJ2vEJDzA8cei7+y9N/elKQ1MFPcCrh qwbT7wlnjdnKgv1VEU9VeBzx3oXV4JCVwxCwsUBtb0kN9X5kwsnTQvZxTAOm/hWDSGup LRxlJ2G0aNMihDNNm1o0P+uYdlO8gpa8UuAqUzefh2OeXuwlZ4kWxxmZku0MnNLTKziw J46w== 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 n123-v6si22138079pfn.9.2018.07.12.00.26.57; Thu, 12 Jul 2018 00:27:13 -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 S1726744AbeGLHee (ORCPT + 99 others); Thu, 12 Jul 2018 03:34:34 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57444 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbeGLHed (ORCPT ); Thu, 12 Jul 2018 03:34:33 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6C7NVOV071250 for ; Thu, 12 Jul 2018 03:26:16 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2k61fxbb0t-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jul 2018 03:26:15 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 12 Jul 2018 08:26:13 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 12 Jul 2018 08:26:10 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w6C7Q9R942270744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Jul 2018 07:26:09 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EA35F52065; Thu, 12 Jul 2018 10:26:30 +0100 (BST) Received: from rapoport-lnx (unknown [9.148.8.135]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTPS id 66F6E52051; Thu, 12 Jul 2018 10:26:30 +0100 (BST) Date: Thu, 12 Jul 2018 10:26:07 +0300 From: Mike Rapoport To: Michal Hocko Cc: Jonathan Corbet , Randy Dunlap , linux-doc , linux-mm , lkml Subject: Re: [PATCH v2 11/11] docs/mm: add description of boot time memory management References: <1530370506-21751-1-git-send-email-rppt@linux.vnet.ibm.com> <1530370506-21751-12-git-send-email-rppt@linux.vnet.ibm.com> <20180703122324.GA23824@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180703122324.GA23824@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 18071207-0020-0000-0000-000002A5A73C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18071207-0021-0000-0000-000020F1F203 Message-Id: <20180712072606.GB4422@rapoport-lnx> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-12_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807120076 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Jul 03, 2018 at 02:23:24PM +0200, Michal Hocko wrote: > On Sat 30-06-18 17:55:06, Mike Rapoport wrote: > > Both bootmem and memblock are have pretty good internal documentation > > coverage. With addition of some overview we get a nice description of the > > early memory management. > > > > Signed-off-by: Mike Rapoport > > Yes this looks reasonable. I would just mention the available debugging > options and CONFIG_ARCH_DISCARD_MEMBLOCK. I'd really prefer to add it as a separate patch rather then resending the whole series. > Other than that looks goot to get a rough idea. Improvements can be done > on top of course. > > Acked-by: Michal Hocko Thanks for the review. I think Jon was mostly concerned about the patch "mm/memblock: add a name for memblock flags enumeration" [1]. Could you please review it as well? [1] https://lore.kernel.org/lkml/1530370506-21751-7-git-send-email-rppt@linux.vnet.ibm.com/ > > --- > > Documentation/core-api/boot-time-mm.rst | 92 +++++++++++++++++++++++++++++++++ > > Documentation/core-api/index.rst | 1 + > > 2 files changed, 93 insertions(+) > > create mode 100644 Documentation/core-api/boot-time-mm.rst > > > > diff --git a/Documentation/core-api/boot-time-mm.rst b/Documentation/core-api/boot-time-mm.rst > > new file mode 100644 > > index 0000000..03cb164 > > --- /dev/null > > +++ b/Documentation/core-api/boot-time-mm.rst > > @@ -0,0 +1,92 @@ > > +=========================== > > +Boot time memory management > > +=========================== > > + > > +Early system initialization cannot use "normal" memory management > > +simply because it is not set up yet. But there is still need to > > +allocate memory for various data structures, for instance for the > > +physical page allocator. To address this, a specialized allocator > > +called the :ref:`Boot Memory Allocator `, or bootmem, was > > +introduced. Several years later PowerPC developers added a "Logical > > +Memory Blocks" allocator, which was later adopted by other > > +architectures and renamed to :ref:`memblock `. There is also > > +a compatibility layer called `nobootmem` that translates bootmem > > +allocation interfaces to memblock calls. > > + > > +The selection of the early allocator is done using > > +``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel > > +configuration options. These options are enabled or disabled > > +statically by the architectures' Kconfig files. > > + > > +* Architectures that rely only on bootmem select > > + ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``. > > +* The users of memblock with the nobootmem compatibility layer set > > + ``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``. > > +* And for those that use both memblock and bootmem the configuration > > + includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``. > > + > > +Whichever allocator is used, it is the responsibility of the > > +architecture specific initialization to set it up in > > +:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions. > > + > > +Once the early memory management is available it offers a variety of > > +functions and macros for memory allocations. The allocation request > > +may be directed to the first (and probably the only) node or to a > > +particular node in a NUMA system. There are API variants that panic > > +when an allocation fails and those that don't. And more recent and > > +advanced memblock even allows controlling its own behaviour. > > + > > +.. _bootmem: > > + > > +Bootmem > > +======= > > + > > +(mostly stolen from Mel Gorman's "Understanding the Linux Virtual > > +Memory Manager" `book`_) > > + > > +.. _book: https://www.kernel.org/doc/gorman/ > > + > > +.. kernel-doc:: mm/bootmem.c > > + :doc: bootmem overview > > + > > +.. _memblock: > > + > > +Memblock > > +======== > > + > > +.. kernel-doc:: mm/memblock.c > > + :doc: memblock overview > > + > > + > > +Functions and structures > > +======================== > > + > > +Common API > > +---------- > > + > > +The functions that are described in this section are available > > +regardless of what early memory manager is enabled. > > + > > +.. kernel-doc:: mm/nobootmem.c > > + > > +Bootmem specific API > > +-------------------- > > + > > +These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n`` > > + > > +.. kernel-doc:: include/linux/bootmem.h > > +.. kernel-doc:: mm/bootmem.c > > + :nodocs: > > + > > +Memblock specific API > > +--------------------- > > + > > +Here is the description of memblock data structures, functions and > > +macros. Some of them are actually internal, but since they are > > +documented it would be silly to omit them. Besides, reading the > > +descriptions for the internal functions can help to understand what > > +really happens under the hood. > > + > > +.. kernel-doc:: include/linux/memblock.h > > +.. kernel-doc:: mm/memblock.c > > + :nodocs: > > diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst > > index f5a66b7..93d5a46 100644 > > --- a/Documentation/core-api/index.rst > > +++ b/Documentation/core-api/index.rst > > @@ -28,6 +28,7 @@ Core utilities > > printk-formats > > circular-buffers > > gfp_mask-from-fs-io > > + boot-time-mm > > > > Interfaces for kernel debugging > > =============================== > > -- > > 2.7.4 > > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike.