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 7F23FECAAD5 for ; Mon, 5 Sep 2022 20:54:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B56EB80205; Mon, 5 Sep 2022 16:53:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B0660801E6; Mon, 5 Sep 2022 16:53:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CDE680205; Mon, 5 Sep 2022 16:53:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8A697801E6 for ; Mon, 5 Sep 2022 16:53:59 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5D0158069D for ; Mon, 5 Sep 2022 20:53:59 +0000 (UTC) X-FDA: 79879233798.21.29B833C Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by imf12.hostedemail.com (Postfix) with ESMTP id 1664240082 for ; Mon, 5 Sep 2022 20:53:58 +0000 (UTC) Received: by mail-qk1-f174.google.com with SMTP id j6so6909804qkl.10 for ; Mon, 05 Sep 2022 13:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=3/RM6NI1xD0KfggIAxAiR262mP+cF5baa1PLRg4NH9k=; b=G9z+EvS2Wqtba+jOm4m0Qbrf2RRYIzrnD3zMzFbZB8qkKbNj5ESH83zXxDU77a4zjl FrtqCU5yfAe13CuDf6LETaMDJdUthJHHXUxPqNPMlSIR3Vs9dp72B4HoJ+pebLtTpV8a kyrf2xtzwrYUITUTGeyH0cFRYYwGUuYjhefkyFc9Gr/EbCLmHKnvBJsHzSVsZHkjCj6g XjEkMmwK97V/siI7AUUvAM+WDwegohtOyngq9z4kWi/EwTunI2XDdv/bu2al0AF1jK2i 00zh3xjpybLOW2e8qVuBBaVkEbWw2MRM80U02hQrU8cxfBViOjCom+Tfi7pvZn9XhlrC +RDw== 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=3/RM6NI1xD0KfggIAxAiR262mP+cF5baa1PLRg4NH9k=; b=JD4+gfKn560JTa1lY3XI1uVRIVMSmpc299ABNQYfmwBDo1qNxH24z04ExB4t7zNocl 5bRsk47pzlNj21/IMfLagbWwLOMyoNjKTMmRQqFKIr0v7XHzTjSg8tb9DQh4Xi7+FLx2 MgzSAM3l5oEVKc4CmTZya/l5p0dGOhX8A0QqwcVZqY+R5aZo2OocJ7d+vKCbQpREFGyy Rc9ho2BGD1fOpheXOgcUci6KEa/GXzZ0atCr88DcMh9t2byPbUNSu2eK/mzENAATntKq 2+gdTvNt3nBSNCbFP3QkLBOfdsMTaeRhR16j9wgx+4HzUUwz9JqG/zP07IvZ8FEBPkhG kslw== X-Gm-Message-State: ACgBeo25Tx8ZS2alUPY6PJLxTJ12gcZO+DysGVNg1K2scRi+iUdfvMjY s0AuAWhyay/qdvV+mChqcdmSLO5GPXcRdui+sX4= X-Google-Smtp-Source: AA6agR7Amw2WalDpZucZ1oitGN5MjQaghekEeU9fuF2XzEtK0QuRIU4bQFyx4PeLU8qCSXja7lgFHquh5uhVEI1WCnI= X-Received: by 2002:a05:620a:843:b0:6be:86a8:4099 with SMTP id u3-20020a05620a084300b006be86a84099mr28542817qku.386.1662411238391; Mon, 05 Sep 2022 13:53:58 -0700 (PDT) MIME-Version: 1.0 References: <20220901044249.4624-1-osalvador@suse.de> <20220901044249.4624-2-osalvador@suse.de> In-Reply-To: From: Andrey Konovalov Date: Mon, 5 Sep 2022 22:53:47 +0200 Message-ID: Subject: Re: [PATCH 1/3] lib/stackdepot: Add a refcount field in stack_record To: Marco Elver , Oscar Salvador Cc: Michal Hocko , Andrew Morton , LKML , Linux Memory Management List , Vlastimil Babka , Eric Dumazet , Waiman Long , Suren Baghdasaryan , Alexander Potapenko , Dmitry Vyukov , kasan-dev Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662411239; a=rsa-sha256; cv=none; b=Danf4LNOMYCDfoKyTgnVkeD21FaLGVt069O55nBfTnBN5PrOAxk0Kw7BIqYQ2FioFqCFzF mDWi0wfrVu7/M1jkG3p18X46IFE7ZOWuAqTYfyl3hhpPYxQDyzHOquAA+i2V+paX/3BDQD OA20R3aQWChPRzjs7DTEbl2+880r+Co= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=G9z+EvS2; spf=pass (imf12.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662411239; 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=3/RM6NI1xD0KfggIAxAiR262mP+cF5baa1PLRg4NH9k=; b=TxPBTr9fMnA8Ugi5wUbeuUsQEMGUgv1e8nJ0NKQDxko4VPxFNwgFVq6WA35ThxOYEevOdn h6bq8OfPtx89GGATfkOaTfKcSiRPwS/5s968JucAMvO9VYAmnAXZ9mbSQ02nU348K9S7Dq Z/BovejeD+KPApnUL/6wFCKmrYBGAhk= Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=G9z+EvS2; spf=pass (imf12.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam12 X-Stat-Signature: fubuxyr6nga3a9is1g81935yunegie6r X-Rspamd-Queue-Id: 1664240082 X-Rspam-User: X-HE-Tag: 1662411238-883592 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, Sep 1, 2022 at 11:18 AM 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. 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). > > We had talked (in the context of KASAN) about bounded stack storage, > but the preferred solution is usually a cache-based design which > allows evictions (in the simplest case a ring buffer), because > figuring out (and relying on) where precisely a stack will > definitively no longer be required in bug reports is complex and does > not guarantee the required bound on memory usage. Andrey has done the > work on this for tag-based KASAN modes: > https://lore.kernel.org/all/cover.1658189199.git.andreyknvl@google.com/ To be clear, the stack ring buffer implementation for the KASAN tag-based modes still uses the stack depot as a back end to store stack traces. I plan to explore redesigning the stack depot implementation to allow evicting unneeded stack traces as the next step. (The goal is to have a memory-bounded stack depot that doesn't just stop collecting stack traces once the memory limit is reached.) Having a refcount for each saved stack trace will likely be a part of this redesign.