Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4373613pxk; Wed, 30 Sep 2020 00:49:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxN77USLAgqTv5XvqPc28sWRx+za5HyJM9F8OVz3Ol3zxZ/3xklfcHB3KXBChtfFP5gf/VB X-Received: by 2002:aa7:da42:: with SMTP id w2mr1300800eds.287.1601452188681; Wed, 30 Sep 2020 00:49:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601452188; cv=none; d=google.com; s=arc-20160816; b=mb+614lPOVHWyco2A9OctIEfqMhgneJKpX9tar/hQwCr0501IvWoB99Wv+XE4yuiiu N97Ggdngii6WbD5mecrGRI/mYNZH5laM7/NzUOpHi7N1nn0XYO/cr4oGY3T/e6vQOX2h fZigdAOCTU8vvoCeeZqIatZ7HKUsnU9Uv1udb8ruz2TYJCp0mN32Gj9/TBULnlD1qLFu 786Oq1k2Ue4BAvGnji8C13E6jFdhYUhB47RX+9PcBEdsyo1AGQ0LEMtSZqKkaHyRYO28 KK74+hO52jaYcGvskgQf321wfXB9AzLbpLBqcmnhQaNOvVpfpRmg8pROUxDYPRQuw2KF bqHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date; bh=gVViBXQ5Pfi8/W3zlW3yNWmp3dQW8rM7G4Ot1shQMH0=; b=MtT/8v6x94Lt7yfu9eAU4LoGkKHUWx7o/3X1haM1fwR19JryjaGFp89bId9CEZwzuN igYp2Mt6R0J/uQabIH5d5Nq7aLVDOogxNk+I/ROsajgxUEXYQRMmPjGxNX/kbJwp5jfn XcpXNgR5k43cqQpHOb1CP5jRrdZQT0YeWUoAZef9MqWH7JIBBUXAOHdqrATjA73jE6Bb 40YWE97uzU9msRR7xlJRxCR0yq4eyNtE7BE3Jdwm1GCNmmDEcJxjTlKwTSxaCVXsGZGa C7xsgWWDsX6DnWaYp+/5hQXYVUF4Ui5XpbfBalssCovkwdrSZ3YZ82WgVdpqP0dkgsyA H99Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a8si589995ejv.661.2020.09.30.00.49.26; Wed, 30 Sep 2020 00:49:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728257AbgI3HsX (ORCPT + 99 others); Wed, 30 Sep 2020 03:48:23 -0400 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:53677 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725440AbgI3HsX (ORCPT ); Wed, 30 Sep 2020 03:48:23 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=richard.weiyang@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0UAYdEKG_1601452096; Received: from localhost(mailfrom:richard.weiyang@linux.alibaba.com fp:SMTPD_---0UAYdEKG_1601452096) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Sep 2020 15:48:16 +0800 Date: Wed, 30 Sep 2020 15:48:16 +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 , Oscar Salvador , Alexander Duyck , Mel Gorman , Michal Hocko , Dave Hansen , Vlastimil Babka , Mike Rapoport , Scott Cheloha , Michael Ellerman Subject: Re: [PATCH v1 3/5] mm/page_alloc: always move pages to the tail of the freelist in unset_migratetype_isolate() Message-ID: <20200930074816.GA40431@L-31X9LVDL-1304.local> Reply-To: Wei Yang References: <20200928182110.7050-1-david@redhat.com> <20200928182110.7050-4-david@redhat.com> <20200929091803.GB36904@L-31X9LVDL-1304.local> <21d9ea16-863b-19fe-e5b7-841bb4228c6d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21d9ea16-863b-19fe-e5b7-841bb4228c6d@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 29, 2020 at 12:12:14PM +0200, David Hildenbrand wrote: >On 29.09.20 11:18, Wei Yang wrote: >> On Mon, Sep 28, 2020 at 08:21:08PM +0200, David Hildenbrand wrote: >>> Page isolation doesn't actually touch the pages, it simply isolates >>> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist. >>> >>> We already place pages to the tail of the freelists when undoing >>> isolation via __putback_isolated_page(), let's do it in any case >>> (e.g., if order <= pageblock_order) and document the behavior. >>> >>> Add a "to_tail" parameter to move_freepages_block() but introduce a >>> a new move_to_free_list_tail() - similar to add_to_free_list_tail(). > >s/a a/a/ > >>> >>> This change results in all pages getting onlined via online_pages() to >>> be placed to the tail of the freelist. >>> >>> Reviewed-by: Oscar Salvador >>> Cc: Andrew Morton >>> Cc: Alexander Duyck >>> Cc: Mel Gorman >>> Cc: Michal Hocko >>> Cc: Dave Hansen >>> Cc: Vlastimil Babka >>> Cc: Wei Yang >>> Cc: Oscar Salvador >>> Cc: Mike Rapoport >>> Cc: Scott Cheloha >>> Cc: Michael Ellerman >>> Signed-off-by: David Hildenbrand >>> --- >>> include/linux/page-isolation.h | 4 ++-- >>> mm/page_alloc.c | 35 +++++++++++++++++++++++----------- >>> mm/page_isolation.c | 12 +++++++++--- >>> 3 files changed, 35 insertions(+), 16 deletions(-) >>> >>> diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h >>> index 572458016331..3eca9b3c5305 100644 >>> --- a/include/linux/page-isolation.h >>> +++ b/include/linux/page-isolation.h >>> @@ -36,8 +36,8 @@ static inline bool is_migrate_isolate(int migratetype) >>> struct page *has_unmovable_pages(struct zone *zone, struct page *page, >>> int migratetype, int flags); >>> void set_pageblock_migratetype(struct page *page, int migratetype); >>> -int move_freepages_block(struct zone *zone, struct page *page, >>> - int migratetype, int *num_movable); >>> +int move_freepages_block(struct zone *zone, struct page *page, int migratetype, >>> + bool to_tail, int *num_movable); >>> >>> /* >>> * Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE. >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>> index 9e3ed4a6f69a..d5a5f528b8ca 100644 >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -905,6 +905,15 @@ static inline void move_to_free_list(struct page *page, struct zone *zone, >>> list_move(&page->lru, &area->free_list[migratetype]); >>> } >>> >>> +/* Used for pages which are on another list */ >>> +static inline void move_to_free_list_tail(struct page *page, struct zone *zone, >>> + unsigned int order, int migratetype) >>> +{ >>> + struct free_area *area = &zone->free_area[order]; >>> + >>> + list_move_tail(&page->lru, &area->free_list[migratetype]); >>> +} >>> + >> >> Would it be better to pass the *to_tail* to move_to_free_list(), so we won't >> have a new function? > >Hi, > >thanks for the review! > >See discussion in RFC + cover letter: > >"Add a "to_tail" parameter to move_freepages_block() but introduce a new >move_to_free_list_tail() - similar to add_to_free_list_tail()." Hmm, sounds reasonable. Reviewed-by: Wei Yang -- Wei Yang Help you, Help me