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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E18D2C43334 for ; Mon, 6 Jun 2022 20:59:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 627D26B0082; Mon, 6 Jun 2022 16:59:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D5B26B0083; Mon, 6 Jun 2022 16:59:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49D386B0085; Mon, 6 Jun 2022 16:59:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 38ADE6B0082 for ; Mon, 6 Jun 2022 16:59:14 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 051B535239 for ; Mon, 6 Jun 2022 20:59:13 +0000 (UTC) X-FDA: 79549026228.12.E334B6E Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by imf10.hostedemail.com (Postfix) with ESMTP id 60993C0021 for ; Mon, 6 Jun 2022 20:58:24 +0000 (UTC) Received: by mail-vs1-f53.google.com with SMTP id q14so14842845vsr.12 for ; Mon, 06 Jun 2022 13:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1t0aPkBseN9ljxb1afmaNtWS3gcXYfMUoZM4UAKpY64=; b=j9fFBxTOyhaMNwI2MHISHBVCDus+IjXviqDS/glHyjdYV9sdqz0Jm0bL3/ScPg27xv lF2Tfru9vTKyMKewDeep2mixoAl016cLOIQYTzkqvUm5SHjs8sVQcrUkrTmPH4sAFcog 00wfCh/1BKxNIWIyy1Q2Om1Z05c1kUIxc18aFuDwSjAQ5AyYq6bYgcITHAK5mi6hCo3t 1Ny6wYA3Mmtdxgo5H+MINKB2zIwW+8LcGts2m566MV4fA7Bu++nC6mn33cBBAIp/lY3J xXdIbCxdPVjgM8C5YOwllV5Sc/Na+2jkTfbTF38SPtZ+ly4gcN8Q1BF4Z/QXDnHUY3Ua va9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1t0aPkBseN9ljxb1afmaNtWS3gcXYfMUoZM4UAKpY64=; b=IKrwLrWH5ERzkwz5X5XVQHCnx7ul6I+xEYw5KDqk0z6GB2KCW1fVZInWGeqiu1NB0s U6fKt3sIOMiagN+cIS9NbSNp3lFqRG/tFNIm7qIViZYuw7tx/WCF4O6pVcFCCyZg3KNb oUDnCTGcUo3rMTfxPLLNyYiE8E+fbQVu8n9XnIKFM9kzzDTv0FSa6FNMXbmH3WWo909H rwhMlykb3orlplRmJz8knJ7FZNuQ7Ym+l03KdqUKKNLQScl1AB0ikJLTgYjaThRdmPGN yndDA274hQ7T/pZL02vhBp8rzD23Ic5jo7LBQ7zDcFuuEHDmWosEnQ22ZkQ4LnrzLiUb IRLA== X-Gm-Message-State: AOAM531mKDE+nCbq72sU9noWuxI3mPjJ3DsiGJzYt8yMH471dSTc5vxq M7nZE1jMux+XXnwF1pSQ5jGzLKeKKTgw8NWxRr8ZWfb+BsxVTw== X-Google-Smtp-Source: ABdhPJy1/zlfqVc+l1cOhAZO3GN8lDy6Ear7NWJVI9VRbkupSqr/fxmXo2YCrhuu0nLKpqu0403IJfOn8BQXkvFjENs= X-Received: by 2002:a17:902:8492:b0:167:6cbf:145b with SMTP id c18-20020a170902849200b001676cbf145bmr11762061plo.26.1654549142272; Mon, 06 Jun 2022 13:59:02 -0700 (PDT) MIME-Version: 1.0 References: <20220604004004.954674-1-zokeefe@google.com> <20220604004004.954674-6-zokeefe@google.com> In-Reply-To: <20220604004004.954674-6-zokeefe@google.com> From: Yang Shi Date: Mon, 6 Jun 2022 13:58:50 -0700 Message-ID: Subject: Re: [PATCH v6 05/15] mm/khugepaged: make allocation semantics context-specific To: "Zach O'Keefe" Cc: Alex Shi , David Hildenbrand , David Rientjes , Matthew Wilcox , Michal Hocko , Pasha Tatashin , Peter Xu , Rongwei Wang , SeongJae Park , Song Liu , Vlastimil Babka , Zi Yan , Linux MM , Andrea Arcangeli , Andrew Morton , Arnd Bergmann , Axel Rasmussen , Chris Kennelly , Chris Zankel , Helge Deller , Hugh Dickins , Ivan Kokshaysky , "James E.J. Bottomley" , Jens Axboe , "Kirill A. Shutemov" , Matt Turner , Max Filippov , Miaohe Lin , Minchan Kim , Patrick Xia , Pavel Begunkov , Thomas Bogendoerfer Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: rey7eqip5nux31nsofobwxq7njtoq3im X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=j9fFBxTO; spf=pass (imf10.hostedemail.com: domain of shy828301@gmail.com designates 209.85.217.53 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 60993C0021 X-HE-Tag: 1654549104-636091 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, Jun 3, 2022 at 5:40 PM Zach O'Keefe wrote: > > Add a gfp_t flags member to struct collapse_control that allows contexts > to specify their own allocation semantics. This decouples the > allocation semantics from > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag. > > khugepaged updates this member for every hugepage processed, since the > sysfs setting might change at any time. > > Signed-off-by: Zach O'Keefe > --- > mm/khugepaged.c | 21 +++++++++++++-------- > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 38488d114073..ba722347bebd 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -92,6 +92,9 @@ struct collapse_control { > > /* Last target selected in khugepaged_find_target_node() */ > int last_target_node; > + > + /* gfp used for allocation and memcg charging */ > + gfp_t gfp; > }; > > /** > @@ -994,15 +997,14 @@ static bool __collapse_huge_page_swapin(struct mm_struct *mm, > return true; > } > > -static int alloc_charge_hpage(struct page **hpage, struct mm_struct *mm, > +static int alloc_charge_hpage(struct mm_struct *mm, struct page **hpage, Why did you have to reverse the order of mm and hpage? It seems pointless and you could save a couple of changed lines. > struct collapse_control *cc) > { > - gfp_t gfp = alloc_hugepage_khugepaged_gfpmask() | __GFP_THISNODE; > int node = khugepaged_find_target_node(cc); > > - if (!khugepaged_alloc_page(hpage, gfp, node)) > + if (!khugepaged_alloc_page(hpage, cc->gfp, node)) > return SCAN_ALLOC_HUGE_PAGE_FAIL; > - if (unlikely(mem_cgroup_charge(page_folio(*hpage), mm, gfp))) > + if (unlikely(mem_cgroup_charge(page_folio(*hpage), mm, cc->gfp))) > return SCAN_CGROUP_CHARGE_FAIL; > count_memcg_page_event(*hpage, THP_COLLAPSE_ALLOC); > return SCAN_SUCCEED; > @@ -1032,7 +1034,7 @@ static void collapse_huge_page(struct mm_struct *mm, unsigned long address, > */ > mmap_read_unlock(mm); > > - result = alloc_charge_hpage(hpage, mm, cc); > + result = alloc_charge_hpage(mm, hpage, cc); > if (result != SCAN_SUCCEED) > goto out_nolock; > > @@ -1613,7 +1615,7 @@ static void collapse_file(struct mm_struct *mm, struct file *file, > VM_BUG_ON(!IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && !is_shmem); > VM_BUG_ON(start & (HPAGE_PMD_NR - 1)); > > - result = alloc_charge_hpage(hpage, mm, cc); > + result = alloc_charge_hpage(mm, hpage, cc); > if (result != SCAN_SUCCEED) > goto out; > > @@ -2037,8 +2039,7 @@ static void khugepaged_scan_file(struct mm_struct *mm, struct file *file, > } > #else > static void khugepaged_scan_file(struct mm_struct *mm, struct file *file, > - pgoff_t start, struct page **hpage, > - struct collapse_control *cc) > + pgoff_t start, struct collapse_control *cc) Why was the !CONFIG_SHMEM version definition changed, but CONFIG_SHMEM version was not? > { > BUILD_BUG(); > } > @@ -2121,6 +2122,9 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, > if (unlikely(khugepaged_test_exit(mm))) > goto breakouterloop; > > + /* reset gfp flags since sysfs settings might change */ > + cc->gfp = alloc_hugepage_khugepaged_gfpmask() | > + __GFP_THISNODE; > VM_BUG_ON(khugepaged_scan.address < hstart || > khugepaged_scan.address + HPAGE_PMD_SIZE > > hend); > @@ -2255,6 +2259,7 @@ static int khugepaged(void *none) > struct mm_slot *mm_slot; > struct collapse_control cc = { > .last_target_node = NUMA_NO_NODE, > + /* .gfp set later */ Seems pointless to me. > }; > > set_freezable(); > -- > 2.36.1.255.ge46751e96f-goog >