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 B2B1BC43334 for ; Tue, 12 Jul 2022 14:17:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D96F94008D; Tue, 12 Jul 2022 10:17:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3886E940063; Tue, 12 Jul 2022 10:17:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22A1594008D; Tue, 12 Jul 2022 10:17:35 -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 169B3940063 for ; Tue, 12 Jul 2022 10:17:35 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id C0F66609BE for ; Tue, 12 Jul 2022 14:17:34 +0000 (UTC) X-FDA: 79678650828.24.4EA607B Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf31.hostedemail.com (Postfix) with ESMTP id 6840420068 for ; Tue, 12 Jul 2022 14:17:33 +0000 (UTC) Received: by mail-pl1-f179.google.com with SMTP id m14so7367946plg.5 for ; Tue, 12 Jul 2022 07:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4Vw+9hy64DZz3B6iurpxZ4BFvPtlf+su5iiagdVYAuA=; b=LxGn8vyqbkcuFmWEdCSyg9sCRmdZ85VV5kvlnEKZvZCbmYKocMCbA9C6y7r08UKnli OXsVSp5U1LT9IHAqmKgic1TBvESAT9oiRkc17tRQgzWpdooTWLZjZ1R+wJ9KA3rwEmm7 sic4WyH/LEB0gKTIFQeZGt0/jltsd7T6PqC3KxvYSCzZZEPlts4zOq7lC0iCd9MHMt1f wsX3SCCmnMUzOUOvP8aHN5QsLaXPAr5kjW5JgIv14Lwk5W960xpsrN3YpKXAAKJYrzxQ S+r9mUJhGt8AFXRoxT9YpfTj0074Z4Ekbfx6EA7Qi8+rwAFqwSzCP7HKNZAuG3EcIkit uDKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4Vw+9hy64DZz3B6iurpxZ4BFvPtlf+su5iiagdVYAuA=; b=TeHIxGj2YsTzqK3EqfYy02Nmr6Prz21yA/Qpzv3fFUuNP/9U5bQ9MSsnu9DbZgkQhr zP0LpmbiHouXUr9VZRDoDQnD8a3dmXJ3f6nC2vY8R0CMbA2Cp4W0MS40+yRjDqffmhCU vJafpZgJ8GZmYWJy4H703YsF0Vb4bl5OGXj/QuBDrEAPD2dZ20Yty7zfUQ0jfYHE1jEg LPXwPfL6HDUt4iVAMtklQRyBQ4nAvNnqs2Rz8H1GKop3LFewps6/Y0OlskyOI4yvhIzP DTyeCfgxrVWiwtXrD7Ony4Bh4q0BBimNe46UiAjMC6srCUIGlD8LWuxMuoEWNIUeKJzu pGog== X-Gm-Message-State: AJIora/cDztevJWrQansVnqBRA6OSBnr0eh4/TLz7i+KVeniomK31Xcz pZ31Ox/OKfGkHRxcl9vbgrYfvg== X-Google-Smtp-Source: AGRyM1uodMGS/GD+553V7G5GvOg8IF/EWRWa7Uo80a1N/9jmvgQxWci5yC0j36DfDJjTo8Fk3Jy/Gw== X-Received: by 2002:a17:90b:3648:b0:1ef:7c45:62cb with SMTP id nh8-20020a17090b364800b001ef7c4562cbmr4816456pjb.132.1657635452174; Tue, 12 Jul 2022 07:17:32 -0700 (PDT) Received: from google.com (55.212.185.35.bc.googleusercontent.com. [35.185.212.55]) by smtp.gmail.com with ESMTPSA id n2-20020a170902968200b00165105518f6sm6832317plp.287.2022.07.12.07.17.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 07:17:31 -0700 (PDT) Date: Tue, 12 Jul 2022 07:17:28 -0700 From: Zach O'Keefe To: Andrew Morton Cc: Alex Shi , David Hildenbrand , David Rientjes , Matthew Wilcox , Michal Hocko , Pasha Tatashin , Peter Xu , Rongwei Wang , SeongJae Park , Song Liu , Vlastimil Babka , Yang Shi , Zi Yan , linux-mm@kvack.org, Andrea Arcangeli , 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 Subject: Re: [mm-unstable v7 03/18] mm/khugepaged: add struct collapse_control Message-ID: References: <20220706235936.2197195-1-zokeefe@google.com> <20220706235936.2197195-4-zokeefe@google.com> <20220708140119.6da1413a413214bc603423e3@linux-foundation.org> <20220711114507.d105b70309a9a5dd2eb57c7a@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220711114507.d105b70309a9a5dd2eb57c7a@linux-foundation.org> ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=LxGn8vyq; spf=pass (imf31.hostedemail.com: domain of zokeefe@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657635453; a=rsa-sha256; cv=none; b=BsvgM3OBivpoD2PUiqQOmEMYtPc9UOrNgSTk1emn6j7WCLo3VubJPfdu/WTa59aUS0dxzs RI56piNvQpJKeoF5YdaCuxWO/fdzf++KbTsrRMNDsXPTTkBHIGK38gDovP/NFdptvxQm/m NBjg/GxZWS6A697ytCY9KHoxhbO9Hn4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657635453; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4Vw+9hy64DZz3B6iurpxZ4BFvPtlf+su5iiagdVYAuA=; b=51NWkFnnH4eDvq9vdZONuOtU/Ho3sWrho/ulHSMoa9DsCE3euxc3yFrASfDixFQ3Sjh4dN XrJtirmtEUXeCL/sY+v1ygBo3ny0on1tty3vF8x6XaRUYi+TIXa+N0qxBDVan2VWwwg8ZQ S7+n7c/IjxGywmBHiDbl+RFiaN5+qoY= Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=LxGn8vyq; spf=pass (imf31.hostedemail.com: domain of zokeefe@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: wr5ai1zicmiwijzow65ib17ro6eqware X-Rspamd-Queue-Id: 6840420068 X-HE-Tag: 1657635453-371066 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 Jul 11 11:45, Andrew Morton wrote: > On Mon, 11 Jul 2022 11:29:13 -0700 "Zach O'Keefe" wrote: > > > On Fri, Jul 8, 2022 at 2:01 PM Andrew Morton wrote: > > > > > > On Wed, 6 Jul 2022 16:59:21 -0700 "Zach O'Keefe" wrote: > > > > > > > Modularize hugepage collapse by introducing struct collapse_control. > > > > This structure serves to describe the properties of the requested > > > > collapse, as well as serve as a local scratch pad to use during the > > > > collapse itself. > > > > > > > > Start by moving global per-node khugepaged statistics into this > > > > new structure. Note that this structure is still statically allocated > > > > since CONFIG_NODES_SHIFT might be arbitrary large, and stack-allocating > > > > a MAX_NUMNODES-sized array could cause -Wframe-large-than= errors. > > > > > > > > Signed-off-by: Zach O'Keefe > > > > --- > > > > mm/khugepaged.c | 87 ++++++++++++++++++++++++++++--------------------- > > > > 1 file changed, 50 insertions(+), 37 deletions(-) > > > > > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > > > index 196eaadbf415..f1ef02d9fe07 100644 > > > > --- a/mm/khugepaged.c > > > > +++ b/mm/khugepaged.c > > > > @@ -85,6 +85,14 @@ static struct kmem_cache *mm_slot_cache __read_mostly; > > > > > > > > #define MAX_PTE_MAPPED_THP 8 > > > > > > > > +struct collapse_control { > > > > + /* Num pages scanned per node */ > > > > + int node_load[MAX_NUMNODES]; > > > > > > Does this actually need to be 32-bit? Looking at the current code I'm > > > suspecting that khugepaged_node_load[] could be a ushort? > > > > > > [And unsigned int would be more appropriate, but we always do that :(] > > > > > > > Hey Andrew, > > > > Thanks for taking the time to review, and good catch - I don't think > > we need 32 bits. > > > > Minimally, we just need to be able to hold the maximum value of > > HPAGE_PMD_NR = 1 << (PMD_SHIFT - PAGE_SHIFT). > > > > I'm not sure what arch/config options (that also use THP) produce the > > minimum/maximum value here. I looked through most of the archs that > > define PMD_SHIFT, and couldn't find an example where we'd need > 16 > > bits, with most cases still requiring > 8 bits. All the various > > configs do get complicated though. > > > > Is it acceptable to use u16, with an #error if HPAGE_PMD_ORDER >= 16? > > It might be ;) > > It was just a thought - perhaps something which you or someone else > might choose to look at, but I don't think this work needs to be part > of the current series, unless the current series consumes egregious > amounts of memory. > I think it makes sense. Reason we moved this struct to kmalloc was MAX_NUMNODES can be pretty large - so might as well save a few bytes for a pretty small change. Yang seems good with it, anyways :)