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 4D3FFC43334 for ; Mon, 11 Jul 2022 18:45:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0C03940018; Mon, 11 Jul 2022 14:45:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBC4F940010; Mon, 11 Jul 2022 14:45:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAB2B940018; Mon, 11 Jul 2022 14:45:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9A786940010 for ; Mon, 11 Jul 2022 14:45:11 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 71F59204B3 for ; Mon, 11 Jul 2022 18:45:11 +0000 (UTC) X-FDA: 79675696422.04.4677F9E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id D16BC100038 for ; Mon, 11 Jul 2022 18:45:10 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1791361507; Mon, 11 Jul 2022 18:45:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF257C341C8; Mon, 11 Jul 2022 18:45:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1657565109; bh=hzfcgEqveyctlWWh32AfQYmoeIzWzhzG/ocF9JHZAAg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=q0ppUJ7g1WLVgHSlvQk1olQ08LZwNGZ7tlCri1StGKDlG4mbUxE4WwhBbaP9PaZ/y G4eZDBbOQt6nl6MNCgCejoE7WS6IePR+yesZi8a+iERKeal0CXJJkom2DTvh5iJont neQOU06V6iw/8lqbFBQCRmAiJ5L8I+sRxruze/68= Date: Mon, 11 Jul 2022 11:45:07 -0700 From: Andrew Morton 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 , 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: <20220711114507.d105b70309a9a5dd2eb57c7a@linux-foundation.org> In-Reply-To: References: <20220706235936.2197195-1-zokeefe@google.com> <20220706235936.2197195-4-zokeefe@google.com> <20220708140119.6da1413a413214bc603423e3@linux-foundation.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657565111; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ed1WJMONyD5J28nm6Lak26s2mkfRgK7ormvanp/yMUI=; b=D/9nPJ3fsF5q5MXtmfzo8YO4w3ijmfet6o1dm2BB0r0l43JDiFCZW64fq8EJojqZNRLSmm 6OUG+Au7RWXINX93FWu92CLuDbAjusvuaQCxC23SU/YZdSUZr4awLSWNawAopLaYKxiBD0 3dd93PolFrojcfGdji0zwmYpFs9iMyk= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=q0ppUJ7g; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657565111; a=rsa-sha256; cv=none; b=Qq3IfasShEqd0pQXc04d74pjyf5a0Yor59kdpJRnQ06vGFyVO5aJtWPvo51L2Wy1WMNpR0 7mAUuOcUay9M27ek+d0CfQSt1jqLmDjMP/5K9Z0fesLz8gnbDSPBZRxCRSmXubhsEE05CY FbCboXKNWy9ZbHdra6wHtobGFz+z2C4= X-Rspamd-Server: rspam02 X-Stat-Signature: 4sc4hjg87kdufpyeyrxepwx5xa5pfgnx X-Rspamd-Queue-Id: D16BC100038 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=q0ppUJ7g; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1657565110-493712 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 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.