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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no 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 84410C43466 for ; Mon, 21 Sep 2020 01:57:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 95AC5207BB for ; Mon, 21 Sep 2020 01:57:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95AC5207BB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C138A900015; Sun, 20 Sep 2020 21:57:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9C69900009; Sun, 20 Sep 2020 21:57:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8B5E900015; Sun, 20 Sep 2020 21:57:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id 8E079900009 for ; Sun, 20 Sep 2020 21:57:06 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 538F73621 for ; Mon, 21 Sep 2020 01:57:06 +0000 (UTC) X-FDA: 77285405652.29.plane50_031008127141 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 2E52F18086CCF for ; Mon, 21 Sep 2020 01:57:06 +0000 (UTC) X-HE-Tag: plane50_031008127141 X-Filterd-Recvd-Size: 3376 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 01:57:04 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R391e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=richard.weiyang@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0U9XKMRq_1600653420; Received: from localhost(mailfrom:richard.weiyang@linux.alibaba.com fp:SMTPD_---0U9XKMRq_1600653420) by smtp.aliyun-inc.com(127.0.0.1); Mon, 21 Sep 2020 09:57:01 +0800 Date: Mon, 21 Sep 2020 09:57:00 +0800 From: Wei Yang To: David Hildenbrand Cc: Wei Yang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hyperv@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, Andrew Morton , Alexander Duyck , Mel Gorman , Michal Hocko , Dave Hansen , Vlastimil Babka , Oscar Salvador , Mike Rapoport , Scott Cheloha , Michael Ellerman Subject: Re: [PATCH RFC 2/4] mm/page_alloc: place pages to tail in __putback_isolated_page() Message-ID: <20200921015700.GA83969@L-31X9LVDL-1304.local> Reply-To: Wei Yang References: <20200916183411.64756-1-david@redhat.com> <20200916183411.64756-3-david@redhat.com> <20200918020758.GB54754@L-31X9LVDL-1304.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Sep 18, 2020 at 09:27:23AM +0200, David Hildenbrand wrote: >On 18.09.20 04:07, Wei Yang wrote: >> On Wed, Sep 16, 2020 at 08:34:09PM +0200, David Hildenbrand wrote: >>> __putback_isolated_page() already documents that pages will be placed to >>> the tail of the freelist - this is, however, not the case for >>> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be >>> the case for all existing users. >>> >>> This change affects two users: >>> - free page reporting >>> - page isolation, when undoing the isolation. >>> >>> This behavior is desireable for pages that haven't really been touched >>> lately, so exactly the two users that don't actually read/write page >>> content, but rather move untouched pages. >>> >>> The new behavior is especially desirable for memory onlining, where we >>> allow allocation of newly onlined pages via undo_isolate_page_range() >>> in online_pages(). Right now, we always place them to the head of the >> >> The code looks good, while I don't fully understand the log here. >> >> undo_isolate_page_range() is used in __offline_pages and alloc_contig_range. I >> don't connect them with online_pages(). Do I miss something? > >Yeah, please look at -mm / -next instead. See > >https://lkml.kernel.org/r/20200819175957.28465-11-david@redhat.com > Thanks, I get the point. > >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me