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 57D4CECAAD1 for ; Thu, 1 Sep 2022 10:21:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9ED8D6B0072; Thu, 1 Sep 2022 06:21:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99DB96B0073; Thu, 1 Sep 2022 06:21:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8651A8D0001; Thu, 1 Sep 2022 06:21:16 -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 78B966B0072 for ; Thu, 1 Sep 2022 06:21:16 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 503C71C602E for ; Thu, 1 Sep 2022 10:21:16 +0000 (UTC) X-FDA: 79863124152.27.0151AC5 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf24.hostedemail.com (Postfix) with ESMTP id EA1F5180072 for ; Thu, 1 Sep 2022 10:21:15 +0000 (UTC) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-334dc616f86so331815177b3.8 for ; Thu, 01 Sep 2022 03:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=dq57C6wCfbAHbefKG8GYTmvvjyg3019DyyLHKt8zuMQ=; b=aimEc3ftsqVQXvwxk2Z52xTHES+wz28tfiscVQ0z7FBJ9dpEGOvABsWukvxWBNRo4e Q1Xj1HusZkX0PzlyaFjWF9UlXKMqWqIiSabeK1XHSuoEEYxzwMIx1HHD6PE+60lzQahP joa7YSF3kMMAg8b2LFENixzbJ1aaBidTxLRIKdfsG4YK669Nk+dR1xg9bbNQ8uG/WBnD ppomJK6w8Kp7ZzKGDzH1Vrin9NN37FuwfCe4tk2Vr6QXdcM9PRiSHeicck4mog0yVA87 DiZG6i2OI684wxiVTO0vVEF9IkM1+mMQCqz/49OOSsOQj8zfAmpdSg3NSO5dlOnea3MN 3ONw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=dq57C6wCfbAHbefKG8GYTmvvjyg3019DyyLHKt8zuMQ=; b=IqrTM8EpC86VXZjv5wA5eX0Pxm0tQQKqOBRzYRb5IlC64C9L3z8mwJtq2QxnXc31mZ 340G9y5gmvIj1PPWW2exZ+LmBbtxVzCDK4r1iv36AU46qyJKEto9DLpbYJS/14IRpI+s rLIKPAWPqRSP9PnFyj/83mu2++agCpFoBqQiBU5eGlA1Hmi8JFA5DfJNLuHgRBjjwo+k uiErkkQgBYsOMdnlwK7mQfGBalAxVPu86NJTH8kHB3hnoKYhLMkxYmrn3AXDIjzMdtu2 Bjeg4AI4jEXgzUTmiUQiXTwhtRLTm4t0PmsnT8f1jeB6XmOKEuYVRyH73FiPlGk/Ie20 WyqQ== X-Gm-Message-State: ACgBeo34rs8fPRwoKC7xsBN7Cf7MdJsU+3I0Re5ZttY5JeH4fVC6Y7QR wzFyyzavLonJFnE+0u8HDvfZU3MPJvCR063V6AQ5dg== X-Google-Smtp-Source: AA6agR4Um8kqsGPdBIvP1swla9DgQaPBT3/UgvHQhsdZBmoYuNHGh9OLWio0Xv2J0qrgmFaURwUd/dglFe3GTtDGF+U= X-Received: by 2002:a81:bb41:0:b0:328:fd1b:5713 with SMTP id a1-20020a81bb41000000b00328fd1b5713mr22919241ywl.238.1662027675106; Thu, 01 Sep 2022 03:21:15 -0700 (PDT) MIME-Version: 1.0 References: <20220901044249.4624-1-osalvador@suse.de> <20220901044249.4624-2-osalvador@suse.de> In-Reply-To: From: Marco Elver Date: Thu, 1 Sep 2022 12:20:38 +0200 Message-ID: Subject: Re: [PATCH 1/3] lib/stackdepot: Add a refcount field in stack_record To: Michal Hocko Cc: Oscar Salvador , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Vlastimil Babka , Eric Dumazet , Waiman Long , Suren Baghdasaryan , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , kasan-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662027675; 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=dq57C6wCfbAHbefKG8GYTmvvjyg3019DyyLHKt8zuMQ=; b=0B/9nvwtwVvB2ueHmY0X+gxhtTO6Yx6Q5Tj+4jR6LtJjCZ6Ju4sNhcLMqu+6ryTTwRwhDw LD9B8gJYaGQiSzqGhyV2fQc6VYmf2b8H7btlWNvaHI7YzcnWHSttXW3s9LqigBUMB5RPM9 fBD1UBy2fpkzcs64O04Cnd8Mfui+DjY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=aimEc3ft; spf=pass (imf24.hostedemail.com: domain of elver@google.com designates 209.85.128.175 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=1662027675; a=rsa-sha256; cv=none; b=NY9efL6Ne82p222cb5CyHyy6BHwgAroiAdlpUCCUVv//GGwXtyYwq///tQVYmMNVIQjahd A/JXJ4GrVnouye+VaUuApkyhb/pOO2JK91qlRt/ZRU8vvVoQZCXPYweJPKc7YUEwzy6qNX EVnO8amcO/nMy43GP1gWbylpqIk5Pxw= Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=aimEc3ft; spf=pass (imf24.hostedemail.com: domain of elver@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Stat-Signature: m388iqbyopcz8h7fpapaqofpix13edrq X-Rspamd-Queue-Id: EA1F5180072 X-Rspamd-Server: rspam05 X-HE-Tag: 1662027675-658024 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 Thu, 1 Sept 2022 at 12:01, Michal Hocko wrote: > > On Thu 01-09-22 11:18:19, Marco Elver wrote: > > On Thu, 1 Sept 2022 at 10:38, Michal Hocko wrote: > > > > > > On Thu 01-09-22 10:24:58, Marco Elver wrote: > > > > On Thu, Sep 01, 2022 at 06:42AM +0200, Oscar Salvador wrote: > > > [...] > > > > > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > > > > > index 5ca0d086ef4a..aeb59d3557e2 100644 > > > > > --- a/lib/stackdepot.c > > > > > +++ b/lib/stackdepot.c > > > > > @@ -63,6 +63,7 @@ struct stack_record { > > > > > u32 hash; /* Hash in the hastable */ > > > > > u32 size; /* Number of frames in the stack */ > > > > > union handle_parts handle; > > > > > + refcount_t count; /* Number of the same repeated stacks */ > > > > > > > > This will increase stack_record size for every user, even if they don't > > > > care about the count. > > > > > > Couldn't this be used for garbage collection? > > > > Only if we can precisely figure out at which point a stack is no > > longer going to be needed. > > > > But more realistically, stack depot was designed to be simple. Right > > now it can allocate new stacks (from an internal pool), but giving the > > memory back to that pool isn't supported. Doing garbage collection > > would effectively be a redesign of stack depot. > > Fair argument. > > > And for the purpose > > for which stack depot was designed (debugging tools), memory has never > > been an issue (note that stack depot also has a fixed upper bound on > > memory usage). > > Is the increased size really a blocker then? I see how it sucks to > maintain a counter when it is not used by anything but page_owner but > storing that counte externally would just add more complexity AFAICS > (more allocations, more tracking etc.). Right, I think keeping it simple is better. > Maybe the counter can be conditional on the page_owner which would add > some complexity as well (variable size structure) but at least the > external allocation stuff could be avoided. Not sure it's needed - I just checked the size of stack_record on a x86-64 build, and it's 24 bytes. Because 'handle_parts' is 4 bytes, and refcount_t is 4 bytes, and the alignment of 'entries' being 8 bytes, even with the refcount_t, stack_record is still 24 bytes. :-) And for me that's good enough. Maybe mentioning this in the commit message is worthwhile. Of course 32-bit builds still suffer a little, but I think we can live with that.