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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 04BA5C433E1 for ; Tue, 4 Aug 2020 10:03:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E0C2922B45 for ; Tue, 4 Aug 2020 10:03:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="LIitEWRZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E0C2922B45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 454808D014E; Tue, 4 Aug 2020 06:03:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 404A18D0081; Tue, 4 Aug 2020 06:03:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F3588D014E; Tue, 4 Aug 2020 06:03:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 176F48D0081 for ; Tue, 4 Aug 2020 06:03:42 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CA8DD181AEF09 for ; Tue, 4 Aug 2020 10:03:41 +0000 (UTC) X-FDA: 77112449442.12.brass34_1017c6e26fa5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 2094918002DB2 for ; Tue, 4 Aug 2020 10:03:41 +0000 (UTC) X-HE-Tag: brass34_1017c6e26fa5 X-Filterd-Recvd-Size: 4756 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Aug 2020 10:03:40 +0000 (UTC) Received: from kernel.org (unknown [87.70.91.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5A96622B40; Tue, 4 Aug 2020 10:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596535419; bh=B9xrpei0Bo8lOQ4/GpWeP/lLc0dF8lSZjAbEwyC8Z/8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LIitEWRZ2r6vfSgRGOd9L45wg9k1zY+ZcZ2/Bag8vTG2bBPAAcebfqAYi/86NL+1j LRhkZnXXomYhcDx7rWkEWtC5DGrdyOqeD9pUQH26pophFeLizz+vNYqDUSXR1idqhM qklDRDhzgJpiCrJ5brl7b4lOCISiLmnbfvLwlqEw= Date: Tue, 4 Aug 2020 13:03:33 +0300 From: Mike Rapoport To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Andrew Morton , Michal Hocko , "Michael S . Tsirkin" , Mike Kravetz , Pankaj Gupta , Baoquan He Subject: Re: [PATCH v3 6/6] mm: document semantics of ZONE_MOVABLE Message-ID: <20200804100333.GC8243@kernel.org> References: <20200804072408.5481-1-david@redhat.com> <20200804072408.5481-7-david@redhat.com> <20200804093323.GB8243@kernel.org> <65deeb21-63fe-d1c1-bb87-74a08035f79a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65deeb21-63fe-d1c1-bb87-74a08035f79a@redhat.com> X-Rspamd-Queue-Id: 2094918002DB2 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Aug 04, 2020 at 11:55:10AM +0200, David Hildenbrand wrote: > On 04.08.20 11:33, Mike Rapoport wrote: > > On Tue, Aug 04, 2020 at 09:24:08AM +0200, David Hildenbrand wrote: > >> Let's document what ZONE_MOVABLE means, how it's used, and which special > >> cases we have regarding unmovable pages (memory offlining vs. migration / > >> allocations). > >> > >> Cc: Andrew Morton > >> Cc: Michal Hocko > >> Cc: Michael S. Tsirkin > >> Cc: Mike Kravetz > >> Cc: Mike Rapoport > >> Cc: Pankaj Gupta > >> Cc: Baoquan He > >> Signed-off-by: David Hildenbrand > > > > Several nits below, othersize > > > > Acked-by: Mike Rapoport > > > >> --- > >> include/linux/mmzone.h | 34 ++++++++++++++++++++++++++++++++++ > >> 1 file changed, 34 insertions(+) > >> > >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > >> index f6f884970511d..600d449e7d9e9 100644 > >> --- a/include/linux/mmzone.h > >> +++ b/include/linux/mmzone.h > >> @@ -372,6 +372,40 @@ enum zone_type { > >> */ > >> ZONE_HIGHMEM, > >> #endif > >> + /* > >> + * ZONE_MOVABLE is similar to ZONE_NORMAL, except that it *primarily* > >> + * only contains movable pages. Main use cases are to make memory > > > > "Primarily only" sounds awkward. Maybe > > > > ... except that it only contains movable pages with few exceptional > > cases described below. > > > > And then > > > > Main use cases for ZONE_MOVABLE are ... > > Ack! > > > > >> + * offlining more likely to succeed, and to locally limit unmovable > >> + * allocations - e.g., to increase the number of THP/huge pages. > >> + * Notable special cases are: > >> + * > >> + * 1. Pinned pages: (Long-term) pinning of movable pages might > > > > ^long, capital L looked out of place for me > > Ack! > > > > >> + * essentially turn such pages unmovable. Memory offlining might > >> + * retry a long time. > >> + * 2. memblock allocations: kernelcore/movablecore setups might create > >> + * situations where ZONE_MOVABLE contains unmovable allocations > >> + * after boot. Memory offlining and allocations fail early. > >> + * 3. Memory holes: Such pages cannot be allocated. Applies only to > >> + * boot memory, not hotplugged memory. Memory offlining and > >> + * allocations fail early. > > > > I would clarify where page struct for abscent memory come from > > Something like: > > Memory holes: We might have a memmap for memory holes, for example, if ^w ;-) > we have sections that are only partially System RAM. Such pages cannot > be ... How about ... sections that are only partially populated ? > ? > > Thanks! > > -- > Thanks, > > David / dhildenb > -- Sincerely yours, Mike.