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=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 ED0A8C433E0 for ; Mon, 11 Jan 2021 04:09:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7C77E22288 for ; Mon, 11 Jan 2021 04:09:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C77E22288 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A6F286B0120; Sun, 10 Jan 2021 23:09:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A482C8D0020; Sun, 10 Jan 2021 23:09:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 910306B0123; Sun, 10 Jan 2021 23:09:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id 7A3486B0120 for ; Sun, 10 Jan 2021 23:09:34 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 351DA8245571 for ; Mon, 11 Jan 2021 04:09:34 +0000 (UTC) X-FDA: 77692165068.08.nerve55_3d0352927509 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 17A881819E773 for ; Mon, 11 Jan 2021 04:09:34 +0000 (UTC) X-HE-Tag: nerve55_3d0352927509 X-Filterd-Recvd-Size: 5654 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 Jan 2021 04:09:33 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id o10so24932387lfl.13 for ; Sun, 10 Jan 2021 20:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JRbCTp+kxr3AXSPRV3xhg0bLNLT4VzvUn0Z63tU3D30=; b=QJnwhAu05K947WCTB0Tnk3GmguiIR5k6mGYtULd5JlqNPdE4lbB1qMCA4eReGXmC3m d1tqg6QqAG4Y6nIamu2HnPUJx9zOAx9Hd3l8G7aNIHMbL4m3wsifOzaHFetRVhxknQTP v6B7OB72QiMT0biubV1/5l4WnrRrfWGBXKgGVqEvZRkklWaNpo0PfAi+5VDmaDsdie07 ris8UdI26xSbc6UI0s4j2YeDBRMkfzXXxltDjheHjG0y6FnmkN4O9gtPCRM/+gPngyBn lRVoePy/tKj376jnu0FyoAUfSLc9dn9676fduFrp2fiex1DnboxrJtSQBEa9pLtjgUjN 8mNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JRbCTp+kxr3AXSPRV3xhg0bLNLT4VzvUn0Z63tU3D30=; b=FzYOxxq3TUG8wo2nP6PgFT2s5nJ8vFVMdo11Ufy7G05kcsAMW+s7CsgAiEmynjZ52f KJJS1yf+ncJ/oruWSufb+FOhwsDG14tOIzstoGcrI4qmufEZ8Scc2fFbVx8UYZiLECf1 rwvj9977XZuXZ375SpLoO0JEWJ/C/3OFNuwiS/hjRbY+kObVpSaaDjjBgEO6irE6qz8U 5zGMjMUqm1vtDRkATgexXSwuZQqRQsyTqaHdkGWuB5+CAlvUpNKACLoW20ZGyaqVx1HU bFHrKhOYMFVSiYNg8Q0OILPpzQ4tYcBORWrK0mpqEEOHYggKCicjBANH8WmgIxX+jvDW mktA== X-Gm-Message-State: AOAM531nht2v6JUu+mr5b2onvZw4Sb+JilvsBfmO4cLyIMBONM65MVfG GPfCidgvTaC8SO75BMAxNrHhLmmbgBuFcG+S0u4= X-Google-Smtp-Source: ABdhPJzT85P22DleIQr94p9kVvrqXvqylXEyf5I9JncJoK5DXk0ewk0mPOAewXiEoNljxci5XAXi2raBVt9JFQ1pICk= X-Received: by 2002:a19:83c9:: with SMTP id f192mr6069276lfd.399.1610338172393; Sun, 10 Jan 2021 20:09:32 -0800 (PST) MIME-Version: 1.0 References: <20210106034918.GA1154@open-light-1.localdomain> <3bfdbe48-5818-7470-4c3b-96e62d387fb4@oracle.com> In-Reply-To: <3bfdbe48-5818-7470-4c3b-96e62d387fb4@oracle.com> From: Liang Li Date: Mon, 11 Jan 2021 12:09:18 +0800 Message-ID: Subject: Re: [PATCH 3/6] hugetlb: add free page reporting support To: Mike Kravetz Cc: Alexander Duyck , Mel Gorman , Andrew Morton , Andrea Arcangeli , Dan Williams , "Michael S. Tsirkin" , David Hildenbrand , Jason Wang , Dave Hansen , Michal Hocko , Liang Li , linux-mm , LKML , virtualization@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" 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 Fri, Jan 8, 2021 at 6:04 AM Mike Kravetz wrote: > > On 1/5/21 7:49 PM, Liang Li wrote: > > hugetlb manages its page in hstate's free page list, not in buddy > > system, this patch try to make it works for hugetlbfs. It canbe > > used for memory overcommit in virtualization and hugetlb pre zero > > out. > > I am not looking closely at the hugetlb changes yet. There seem to be > higher level questions about page reporting/etc. Once those are sorted, > I will be happy to take a closer look. One quick question below. > > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -41,6 +41,7 @@ > > #include > > #include > > #include > > +#include "page_reporting.h" > > #include "internal.h" > > > > int hugetlb_max_hstate __read_mostly; > > @@ -1028,6 +1029,9 @@ static void enqueue_huge_page(struct hstate *h, struct page *page) > > list_move(&page->lru, &h->hugepage_freelists[nid]); > > h->free_huge_pages++; > > h->free_huge_pages_node[nid]++; > > + if (hugepage_reported(page)) > > + __ClearPageReported(page); > > + hugepage_reporting_notify_free(h->order); > > } > > > > static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid) > > @@ -5531,6 +5535,21 @@ follow_huge_pgd(struct mm_struct *mm, unsigned long address, pgd_t *pgd, int fla > > return pte_page(*(pte_t *)pgd) + ((address & ~PGDIR_MASK) >> PAGE_SHIFT); > > } > > > > +void isolate_free_huge_page(struct page *page, struct hstate *h, int nid) > > +{ > > + VM_BUG_ON_PAGE(!PageHead(page), page); > > + > > + list_move(&page->lru, &h->hugepage_activelist); > > + set_page_refcounted(page); > > +} > > + > > +void putback_isolate_huge_page(struct hstate *h, struct page *page) > > +{ > > + int nid = page_to_nid(page); > > + > > + list_move(&page->lru, &h->hugepage_freelists[nid]); > > +} > > The above routines move pages between the free and active lists without any > update to free page counts. How does that work? Will the number of entries > on the free list get out of sync with the free_huge_pages counters? > -- > Mike Kravetz > Yes. the free_huge_pages counters will be out of sync with the free list. There are two reasons for the above code: 1. Hide the free page reporting to the user; 2. Simplify the logic to sync 'free_huge_pages' and 'resv_huge_pages'. I am not sure if it will break something else. Thanks Liang