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 C480FC433EF for ; Fri, 13 May 2022 23:05:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EDC06B0073; Fri, 13 May 2022 19:05:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29D966B0075; Fri, 13 May 2022 19:05:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 165976B0078; Fri, 13 May 2022 19:05:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0418E6B0073 for ; Fri, 13 May 2022 19:05:21 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id C195612086A for ; Fri, 13 May 2022 23:05:20 +0000 (UTC) X-FDA: 79462252800.27.47D80CC Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf23.hostedemail.com (Postfix) with ESMTP id 6F541140017 for ; Fri, 13 May 2022 23:05:05 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id y32so16861285lfa.6 for ; Fri, 13 May 2022 16:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pZfsoGSsZhROwz0bPnR4Xwb6OZIWIqqNXTBr4YgvOoM=; b=HMODtXza2p+BIq5eAgRnZlZEBY1K/gJ0nov0Hu2qI9vqZOAYzsmX9Q6pEsY0I9fido Lq31AXVDx44tP7p9Y6jXouQNJjIX+IaFEVD8COh5tg+GVExmjyh1wF3MBfA6sGORrdYJ pKRpDrfYtR6wYpl+ynrHkGiHXFp/h/bDgJaQtV/ymVg9koVyS2yMfvpak7QGbjU4qlNU t7jv84eNzs6vGtgivxdsHQsuqmzt6tBJzR5866co+2hk2omKMEpalkbEWVvs57hTBneI 6O/Yit9aFdyEhk2fefAY/tkLY+JozBIyDs/8yVZLydudkVmeWcBrJ4XxHqpp1pFck0s8 qj/w== 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=pZfsoGSsZhROwz0bPnR4Xwb6OZIWIqqNXTBr4YgvOoM=; b=vR7N20DkRnY4swZxH+1VAGKOf6nKBCfgOj17hcLL0GfeRVETDxrrz/FL+v7fSDLt9Z Zm/XNiuvFEkYfkBB2M1MZUgFYysQSzLklErGnPQ8paRqi2rIZaTEAbj1gK2K/OqO/P9l xN7SAvkKcp0pqrIRS94k9hPZwM69AyYqPUHg7BFuoOiakThwcKLSQFwA6ojoxOdz5F6m 6341fx1UhSVZ37uTK4jm5i7dC17b9vB+apyt7okUVus79OPd+w46hxTAKfbiBMN4adZH GnTecD+CRsgtuKz3jfSLjjC35HBpNFFb0RP81X1rco5MJOob0LFZxVDpHi8tgSKRqoo3 NfuQ== X-Gm-Message-State: AOAM533zPBvYf0EB+d8tgU5+qHMiK+nVnMBxRwFXM/f2Z1UmtAcsFQ6O X9d5hWjRq3aNWMh+SZ4f3TTIVzl3fuPVKotnaSF4oA== X-Google-Smtp-Source: ABdhPJxWC2VNi7hx4D6SUFj1JE868I5TuYpzbUzt0K5ijxAgFAxtelrprXtwUnS+YqiAqSs7SXZaUqFAj7uBC+MMyWQ= X-Received: by 2002:a05:6512:b0f:b0:474:18c:8b9e with SMTP id w15-20020a0565120b0f00b00474018c8b9emr5123250lfu.354.1652483118391; Fri, 13 May 2022 16:05:18 -0700 (PDT) MIME-Version: 1.0 References: <20220504214437.2850685-1-zokeefe@google.com> <20220504214437.2850685-5-zokeefe@google.com> In-Reply-To: From: "Zach O'Keefe" Date: Fri, 13 May 2022 16:04:41 -0700 Message-ID: Subject: Re: [PATCH v5 04/13] mm/khugepaged: make hugepage allocation context-specific To: David Rientjes Cc: Alex Shi , David Hildenbrand , Matthew Wilcox , Michal Hocko , Pasha Tatashin , Peter Xu , SeongJae Park , Song Liu , Vlastimil Babka , Yang Shi , Zi Yan , linux-mm@kvack.org, 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-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6F541140017 X-Stat-Signature: zo75qh9afw8whykcw4ci5i84effra9qf Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=HMODtXza; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of zokeefe@google.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=zokeefe@google.com X-Rspam-User: X-HE-Tag: 1652483105-54562 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: Thanks for the review, David! On Thu, May 12, 2022 at 1:02 PM David Rientjes wrote: > > On Wed, 4 May 2022, Zach O'Keefe wrote: > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > index c94bc43dff3e..6095fcb3f07c 100644 > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -92,6 +92,10 @@ struct collapse_control { > > > > /* Last target selected in khugepaged_find_target_node() */ > > int last_target_node; > > + > > + struct page *hpage; > > + int (*alloc_charge_hpage)(struct mm_struct *mm, > > + struct collapse_control *cc); > > }; > > > > /** > > Embedding this function pointer into collapse_contol seems like it would > need some pretty strong rationale. Not to say that it should be a > non-starter, but I think the changelog needs to clearly indicate why this > is better/cleaner than embedding the needed info for a single allocation > and charge function to use. If the callbacks would truly be so different > that unifying them would be more complex, I think this makes sense. Mostly, this boils down to khugepaged having different a allocation pattern for NUMA/UMA ; the former scans the pages first to determine the right node, the latter preallocates before scanning. khugepaged has the luxury on UMA systems of just holding onto a hugepage indefinitely for the next collapse target. For MADV_COLLAPSE, we never preallocate, and so its pattern doesn't depend on NUMA or UMA configs. Trying to avoid "if (khugepaged) ... else" casing, defining this as a context-defined operation seemed appropriate. Collapsing both alloc and charging together was mostly a code cleanliness decision resulting from not wanting to embed a ->gfp() hook (gfp flags are used both by allocation and memcg charging). Alternatively, a .gfp member could exist - it would just need to be refreshed periodically in the khugepaged codepath. That all said - let me take another crack at seeing if I can make this work without the need for a function pointer here.