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 E6769C4829E for ; Thu, 15 Feb 2024 08:17:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 317088D000E; Thu, 15 Feb 2024 03:17:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C6FB8D0006; Thu, 15 Feb 2024 03:17:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 119CB8D000E; Thu, 15 Feb 2024 03:17:39 -0500 (EST) 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 F21B58D0006 for ; Thu, 15 Feb 2024 03:17:38 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8895D160217 for ; Thu, 15 Feb 2024 08:17:38 +0000 (UTC) X-FDA: 81793334196.12.DAE09C1 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf21.hostedemail.com (Postfix) with ESMTP id E6C751C0012 for ; Thu, 15 Feb 2024 08:17:36 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=D2PPWxqz; spf=pass (imf21.hostedemail.com: domain of elver@google.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707985056; 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=fOVmPP6lQ2riMOBP13temKZcA4Pty/mUrj2ihpJln/U=; b=rWFhUMAr8gy6+tVG029VzXzwChZwdX7j7x60A7UZEyhP3HvORF0K4K+fQwXr9AsOvIrvlc nT5dRLEKTJ3EvF9S90VvmpsQi58qbX1564yu9dRyk+LUoUW0ORrV7JtT7uQqT6OTAXn3VE 2ZY2nJg7QE71gO6xd3ndIXG2urqgyGo= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=D2PPWxqz; spf=pass (imf21.hostedemail.com: domain of elver@google.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707985056; a=rsa-sha256; cv=none; b=3KE+a9wEJ1mdbLwZ3OkT/lLUorUMmXMAWMl6BMaKG5u/yF3N/nTaue7tlTzJRZmxdKHhq3 r/uChn2Sdztvmh83MyAoliPjNJSiErun0DmoyEGr1NU60PvhOFP8rGFrQo5vOxqMUL03Rq RgoYbs14gRpDBxj9OvRzyZ2zX29A8RA= Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-7d6a772e08dso239804241.2 for ; Thu, 15 Feb 2024 00:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707985056; x=1708589856; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fOVmPP6lQ2riMOBP13temKZcA4Pty/mUrj2ihpJln/U=; b=D2PPWxqzqVuOIHbfTE1ZBJNB6pYlDxZYWjAopp+v1piO8Heirugi9XM3esDeV4fcnA Zoh5gBGdhrRotvoj6Brh4hqdJpbMhX4FL9cb48QM158TFO+r4MCkfEgmLLl5bvdsITNn /Byt3Po2TNWdBgVaHnxMIwrpA7U/daQ8Udzjb8rihhEB9ZAgo8HbUWzsGbJcBa2aFd+L /70Xfs8cPCHHeDICfWDoMcE01LCjnaO7OwpbUtSM+hCvaADJ0pYUFCEtxsaNSSUu3WaW mUSJYEpVauZv7D/sEwt0Ne6GYxW9s9RouYW/2a/CeyGAsIpemsZ4lEuMQZzpuh655QyU Mkcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707985056; x=1708589856; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fOVmPP6lQ2riMOBP13temKZcA4Pty/mUrj2ihpJln/U=; b=wPgLRteTFmR3Cq/z95atkOuH/qeFn3/IuPvnfFltWx/zZZSCfzzAKmJQGM3fvgbqyz TDy3t0xkW0gR5+yu/eM4y2KpiYzSKuB0rouYtcbcOjli2mw/av6KPDL5Pgywoecw1TuU zBhFlQDmDFSl9Vjp4o2wUtvXK5bdHFViB9b83D7cYH9PjCc01mwF9k72LvD2tTfpxG4p 0SNVrSpyRbHL5dD6C9k8hR8/jvqzt2pkGI7d+ufZs+BkvkuGHDd6vvjWgWCBZmhtM0K0 CVvKE+Y4LWl3Y3vXMJleGB2yn1TBBL5kGUtxlgo7x4U0SNSXhbIphy7ITvJDcAL9wv4r BnLA== X-Forwarded-Encrypted: i=1; AJvYcCX4ZI6wyvqcM+klmYVdnpSxTPqQEiDDxAJ+N7Zqdt8a4Jg7S4BNS/orLcCdoINpQohTSt/5Cfa5r/JONANb/ZzTVRs= X-Gm-Message-State: AOJu0Ywufs5bPFVlEG8OIwF5mAOBmevUGPyTes1cTPpL97Doaa9tVl1Q +U5RGXpoI9t6o+d06lyr15TGKH0qNHYatLOVVb3SLU+KQVBM3iXozD7pdtCv66vF150qFV+/0xF g4Hn46o2PUmFo2TUaTJD5QoxF8CgsKAPl7Syk X-Google-Smtp-Source: AGHT+IHwqMAMNut0/kXd7nN2WbGlppHAuHdkJ2b3rdaD3wbBRsbiRq7IfGLC/ircqJtgxyn2SxB+ScFA7uw53jct6jA= X-Received: by 2002:a05:6102:304c:b0:46c:f977:4f9f with SMTP id w12-20020a056102304c00b0046cf9774f9fmr1386243vsa.0.1707985055778; Thu, 15 Feb 2024 00:17:35 -0800 (PST) MIME-Version: 1.0 References: <20240214170157.17530-1-osalvador@suse.de> <20240214170157.17530-3-osalvador@suse.de> In-Reply-To: <20240214170157.17530-3-osalvador@suse.de> From: Marco Elver Date: Thu, 15 Feb 2024 09:16:58 +0100 Message-ID: Subject: Re: [PATCH v9 2/7] lib/stackdepot: Move stack_record struct definition into the header To: Oscar Salvador Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Andrey Konovalov , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E6C751C0012 X-Rspam-User: X-Stat-Signature: uchu8wdum3cdubs7s61wc45owprz5x7e X-Rspamd-Server: rspam01 X-HE-Tag: 1707985056-952317 X-HE-Meta: U2FsdGVkX1+C9lJisYhwXzlT8gPaigpPKacXB98zAqqbHYsSxB0zjcFRjz2PCp65hzXN/YAWnw3WyA63Fa+rwSGtLCFXjfDRsFHzm3d79yNzwlbhfUW31g4fezNVz5fpynrZvw8CHtOnP2xlR7mO/TJIGVnpMWluKDAPEzskCTvRlV+MTK7sq9Jo2tnqMSMdB/5TKy2bO+8oC9/QnRckOtRXUCAudoVjmVabN2vWFuewtQguLiJtmBmFdk7bmzyZannjoFYIakZKMus9MdO4us96yRib124L9VCel8G54aJyhs+ziKG0rwH8nqmGZgwIiaoBiBJ2qVwA+O5f5VnA1Ox755XaeukZsSrWr1wUHumXEPTQPOWOegchPOyKvyIy4l9snMycVoZ52WuneFC0JcKKWd3RVlUSAeirbry1PQJzVzCEAK5RShNWGVEcRLrei6aD9hIz1rWHXHbnoDGrpSD1Ygux3lS7hoXz3UAdjTA6hie2BDpRXGA8nlmAm7nTpCa64+5SIMmc9s+mng4ubNAHS8m3KuC2yWKqbXkP0PboDXjkn8xJx/l8Exqwp1jnBliOnQNLF8L9ep7FH2TfNoHkWmalWYjzL9QndDj9m6cEjvi1q3C1H2Uacsh1aIX+qd0AAevdyKnNucLV/CWgsCzkQwbCkmRgYPZlPfSNqFIu0t9g1JRyBtmrA/TuBQ2uR/Lx1ebWZ7fYYWqCiwQnDgdtLvw3hqnj6DOZ+8Lt91ugGig09atXBlR/YPY6J0QTQPaQy2T/dKuHcMQr9aPoJTxMsL8nPSheATtoSq2n733vneDpE7HarpJsKbUYfP2jqZwnXyP1EMmaGdRsB3u1uX17q7yIp9ePCxo7ryE8HRJlwvp+rimbIrkGbbgqK+4QIXOz2eADOfYmppA6hUYVXP/JsicmixMBbawy1OyoMzv9VyBZiofN8zJlH35XJhF7ofYBKn/x7fp9vSalc9N nDAhjQTx qM81NlRIXymFMa7Z6iPVSmZSWWG2Ecqpx6YfXXKXHc91NZHw= 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: List-Subscribe: List-Unsubscribe: On Wed, 14 Feb 2024 at 18:00, Oscar Salvador wrote: > > In order to move the heavy lifting into page_owner code, this one > needs to have access to the stack_record structure, which right now > sits in lib/stackdepot.c. > Move it to the stackdepot.h header so page_owner can access > stack_record's struct fields. > > Signed-off-by: Oscar Salvador > Reviewed-by: Marco Elver > Reviewed-by: Vlastimil Babka > --- > include/linux/stackdepot.h | 47 ++++++++++++++++++++++++++++++++++++++ > lib/stackdepot.c | 45 +----------------------------------- > 2 files changed, 48 insertions(+), 44 deletions(-) > > diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h > index adcbb8f23600..c4b5ad57c066 100644 > --- a/include/linux/stackdepot.h > +++ b/include/linux/stackdepot.h > @@ -30,6 +30,53 @@ typedef u32 depot_stack_handle_t; > */ > #define STACK_DEPOT_EXTRA_BITS 5 > > +#define DEPOT_HANDLE_BITS (sizeof(depot_stack_handle_t) * 8) > + > +#define DEPOT_POOL_ORDER 2 /* Pool size order, 4 pages */ > +#define DEPOT_POOL_SIZE (1LL << (PAGE_SHIFT + DEPOT_POOL_ORDER)) > +#define DEPOT_STACK_ALIGN 4 > +#define DEPOT_OFFSET_BITS (DEPOT_POOL_ORDER + PAGE_SHIFT - DEPOT_STACK_ALIGN) > +#define DEPOT_POOL_INDEX_BITS (DEPOT_HANDLE_BITS - DEPOT_OFFSET_BITS - \ > + STACK_DEPOT_EXTRA_BITS) > + > +#ifdef CONFIG_STACKDEPOT > +/* Compact structure that stores a reference to a stack. */ > +union handle_parts { > + depot_stack_handle_t handle; > + struct { > + /* pool_index is offset by 1 */ > + u32 pool_index : DEPOT_POOL_INDEX_BITS; > + u32 offset : DEPOT_OFFSET_BITS; > + u32 extra : STACK_DEPOT_EXTRA_BITS; > + }; > +}; > + > +struct stack_record { > + struct list_head hash_list; /* Links in the hash table */ > + u32 hash; /* Hash in hash table */ > + u32 size; /* Number of stored frames */ > + union handle_parts handle; /* Constant after initialization */ > + refcount_t count; > + union { > + unsigned long entries[CONFIG_STACKDEPOT_MAX_FRAMES]; /* Frames */ > + struct { > + /* > + * An important invariant of the implementation is to > + * only place a stack record onto the freelist iff its > + * refcount is zero. Because stack records with a zero > + * refcount are never considered as valid, it is safe to > + * union @entries and freelist management state below. > + * Conversely, as soon as an entry is off the freelist > + * and its refcount becomes non-zero, the below must not > + * be accessed until being placed back on the freelist. > + */ > + struct list_head free_list; /* Links in the freelist */ > + unsigned long rcu_state; /* RCU cookie */ > + }; > + }; > +}; > +#endif > + > typedef u32 depot_flags_t; > > /* > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > index c043a4186bc5..4a661a6777da 100644 > --- a/lib/stackdepot.c > +++ b/lib/stackdepot.c > @@ -36,55 +36,12 @@ > #include > #include > > -#define DEPOT_HANDLE_BITS (sizeof(depot_stack_handle_t) * 8) > - > -#define DEPOT_POOL_ORDER 2 /* Pool size order, 4 pages */ > -#define DEPOT_POOL_SIZE (1LL << (PAGE_SHIFT + DEPOT_POOL_ORDER)) > -#define DEPOT_STACK_ALIGN 4 > -#define DEPOT_OFFSET_BITS (DEPOT_POOL_ORDER + PAGE_SHIFT - DEPOT_STACK_ALIGN) > -#define DEPOT_POOL_INDEX_BITS (DEPOT_HANDLE_BITS - DEPOT_OFFSET_BITS - \ > - STACK_DEPOT_EXTRA_BITS) > #define DEPOT_POOLS_CAP 8192 > -/* The pool_index is offset by 1 so the first record does not have a 0 handle. */ > +/* The pool_index is offset by 1 so the first record does not have a 0 handle */ Why this comment change? We lost the '.' -- for future reference, it'd be good to ensure unnecessary changes don't creep into the diff. This is just nitpicking, and I've already reviewed this change, so no need to send a v+1.