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 97A9AC433EF for ; Mon, 11 Jul 2022 18:29:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A874940014; Mon, 11 Jul 2022 14:29:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13250940010; Mon, 11 Jul 2022 14:29:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1433940014; Mon, 11 Jul 2022 14:29:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DB97E940010 for ; Mon, 11 Jul 2022 14:29:50 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id ABF7E60A02 for ; Mon, 11 Jul 2022 18:29:50 +0000 (UTC) X-FDA: 79675657740.08.8ACE849 Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by imf16.hostedemail.com (Postfix) with ESMTP id 4FB8E180082 for ; Mon, 11 Jul 2022 18:29:50 +0000 (UTC) Received: by mail-oi1-f170.google.com with SMTP id r82so7692450oig.2 for ; Mon, 11 Jul 2022 11:29:50 -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=g4hrLz60SjcthLnv6OkqmvhWAblb/W2w3ssPGUPwfXc=; b=iWO1A2t+W7CAEHVPgrPng4TE6w9vS/V6NyMmGXUc9p9QRw/+OqNIluUYIPVeU6OAl6 /nQqi11L/YPl5jbohey5d/bT894tNTnSYmZ73mGlVwksWJ7blZ2wUMUEmg1mU6Z9qmS+ FwRDMbpqOxgG11kk5A8SHsMZbKKqWZSfWCx56d4joswbnsORE+TdOJImrxIBzmsyE5BP u6FuKqaUuf1n57zrtlIUsLejx1JZDnDf+8tMDhzM+3KHDUiMSW6WF3dlH7fLWU5n1WZI orYId504bWAm3G8Iak2l8R0cPsQRoRU+FUKFIssP2cW2Veja1x+mVIREPw/TWo1Qe+2h j03Q== 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=g4hrLz60SjcthLnv6OkqmvhWAblb/W2w3ssPGUPwfXc=; b=lFHZvOIqKj4z21nCThglZ0cJ4qLejgmBt6fwtp2M/kV9gA7Jbopf7bolC1b3SNudyB m3f7F8Knyx3wgN7/DG58qPuIBLs52tXF+ZhXrVR8+7pQUNlw5ctmvaPN1IcspNlN4zfC +VEc1/Dye4bPW0fx/ALrbLYA/wvnnLf3r6UzIF/BcjLEoypX3K4PWTSIz9FrkHv7cZ5O +0ZJcHn1VXXOmQFuVyf7aZ9vf8vIpfKu342pUZkdBNo5XR11zzmlttrRuwN/TbYTLLjW a9LCtARsGQFieE34Hrj2FybAosqU87rBRg8GAZIoqf2Lc0oFjq8rPpFUpR1hiTiUuTeR Se/Q== X-Gm-Message-State: AJIora883PWxvGKaiS779fUuBb7Xg9OqhQkT2XHH1U/f8yYoz2dXrnJL 55pba/+bkm1UCjZYfuOIS40ebIcsuEObOeVabf181A== X-Google-Smtp-Source: AGRyM1unNySLqc7y5faXcRb7jBgzPqfpJetLF8tJ/RLrAa3IfCTEpBluxVuK52RfeW9ub0WLLDFiRe/fnn04TzpFzBY= X-Received: by 2002:a05:6808:aa9:b0:339:fd76:d679 with SMTP id r9-20020a0568080aa900b00339fd76d679mr3671608oij.220.1657564189303; Mon, 11 Jul 2022 11:29:49 -0700 (PDT) MIME-Version: 1.0 References: <20220706235936.2197195-1-zokeefe@google.com> <20220706235936.2197195-4-zokeefe@google.com> <20220708140119.6da1413a413214bc603423e3@linux-foundation.org> In-Reply-To: <20220708140119.6da1413a413214bc603423e3@linux-foundation.org> From: "Zach O'Keefe" Date: Mon, 11 Jul 2022 11:29:13 -0700 Message-ID: Subject: Re: [mm-unstable v7 03/18] mm/khugepaged: add struct collapse_control 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657564190; a=rsa-sha256; cv=none; b=KG0Z2d8+lgc+J9hoVTj1fii6P11NdpeNQzQUjbYiOaj+l5bVWV38410pJn5mmkZSZlv9yu dS/9hipxIGek4fdlZOw5bWGePIkvY+1CgDznNveTwmkKMnPetgfavgIGWEsqwgXW7ZpvTq fdSpYk8fDMVWGUVJGW5ESY3dObDiiM4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657564190; 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=g4hrLz60SjcthLnv6OkqmvhWAblb/W2w3ssPGUPwfXc=; b=s8PLYUs8yRwPI0nL8FHfsX2J5HD41LpOy7HK1x3kYuLyJji4LNLWBqhAAinVoDezqYf05G slwbS8wgXEGF0CrTjIvgW+Z1z6ZQRapWGXiJrvJhX5lhECHR2czwL+YtFhlgIeD09KW/lg nuN08wh4VPUIPCzno/evEaFlGgiktG4= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iWO1A2t+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of zokeefe@google.com designates 209.85.167.170 as permitted sender) smtp.mailfrom=zokeefe@google.com Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iWO1A2t+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of zokeefe@google.com designates 209.85.167.170 as permitted sender) smtp.mailfrom=zokeefe@google.com X-Rspamd-Server: rspam03 X-Stat-Signature: nmcjkom3fm1dm67gko6wdpiae1cu78ty X-Rspamd-Queue-Id: 4FB8E180082 X-Rspam-User: X-HE-Tag: 1657564190-330804 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, 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? Thanks, Zach