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 38D7BECAAD3 for ; Thu, 1 Sep 2022 09:18:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD18D6B0072; Thu, 1 Sep 2022 05:18:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B81B78D0003; Thu, 1 Sep 2022 05:18:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A498F8D0002; Thu, 1 Sep 2022 05:18:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9405E6B0072 for ; Thu, 1 Sep 2022 05:18:56 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7130A80DA6 for ; Thu, 1 Sep 2022 09:18:56 +0000 (UTC) X-FDA: 79862967072.27.55A2FB8 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf01.hostedemail.com (Postfix) with ESMTP id 2B2C140053 for ; Thu, 1 Sep 2022 09:18:56 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-33dc31f25f9so330529007b3.11 for ; Thu, 01 Sep 2022 02:18:55 -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=ofyTx4HKrXBAG7we5X7Qai/eK2K43C5jxgUz5nh/Yro=; b=DNWL+HfERAfAtjtdicaVsZrEdzV4N3Vw5nQ7XoQB5JVkpg5p8Lsx+iFTSKvtyCFj5u BAfxBIvqMTTrW79mMYA44nyO0vqrbHf0Mc0d6NIllyaZ+83qZ0DGOTlWDkqrmDfiFUBg Uarv4p7UHZor3SU51nWN/bvVjMMHzk7sZhJB6O0Y6OqzyJhhnhBEpTygZ6N+7k/hbIST vZ2QhDDBCROSeFX8TMsw8gkqJpObIOjwYdFIC5Hx0mayX6/hIUz5nT4hj1yABlepUqM4 1PjoU84RkgqZApPhBtpAkTXjpToOqeRjtEv9GgqlCBJXqeaEu4nsMq3SJXKWs4bw2g9v EQZw== 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=ofyTx4HKrXBAG7we5X7Qai/eK2K43C5jxgUz5nh/Yro=; b=VcF4ZtVA9pL78lAppyJ3GGjtgMFvVK1CDZMpJsDK3cur7Tu/7PZ9BqeHuqVMp/npLg SXQ2Z4Sjuellja4WdgqFTFrgz/snmUG5odu9euqqZXftTDfNfeqcSRom2pgQ/uzV4je6 uuXR+/k/TE4wV4chnuYjekKvXBW2Y0aqpk9AaYxZZn/4kV8vesoeBKVuuRRyfvnytvoD f6lM7uCuYbo7uQxiac81Gm2uokmsg6Tk8xhbkJ4u9F/KdkRbnjwzC6v0d86k7lWKhIfs 5ryu4IZ1zyE/cMs8hjU4VDMehfxw+oG7CiaU+6O3s+HpiF2swjZ5M9KNPBTgPjVM8xVP u8vQ== X-Gm-Message-State: ACgBeo3DFnjeNC49ltAlNCoDcoXNyVIyfVBzH+xlJ93ejuLOU/iA91lj nebZnjPSSrswZONr6ick1FEeStSDHudl68N4mbNNeQ== X-Google-Smtp-Source: AA6agR4YzkMcE//RozLPe3AlZMR1RsPsbQRd1aguh7fbGIubS9uQzS9d0L0VXutUFfemJr0JfjfopiWBTfT/BVDRmY8= X-Received: by 2002:a0d:ea49:0:b0:33d:bce7:25c2 with SMTP id t70-20020a0dea49000000b0033dbce725c2mr21912903ywe.267.1662023935298; Thu, 01 Sep 2022 02:18:55 -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 11:18:19 +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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662023936; a=rsa-sha256; cv=none; b=4FE39R9otycZvuKC4uFIhfr2s6fWtz3PUvNtiypQ6IwxqlLWTjQE4UowpuRDCJX3kYimsZ y2CV9WwouA4is3iBMBvCQksvLow7f0EV/8B2Nk92iSpFzlOLMfeBOUDIyel11UDFLi7q9y nkazJOlqkF33mv5ZnZyn7YWHKSf5Sbs= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=DNWL+HfE; spf=pass (imf01.hostedemail.com: domain of elver@google.com designates 209.85.128.181 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=1662023936; 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=ofyTx4HKrXBAG7we5X7Qai/eK2K43C5jxgUz5nh/Yro=; b=hzXM6VIwNkIrzR5vQBD81MrK1miq63zO0FDPoJAixK6so788QyuDovmuCeoWBvaeZWX2kf H3O65ji/41n5xkrUq/vDiaYz1WDNcesSlAWG9GkPr921ns0PhTpaJWTMMA8hu5IZA3YcbJ XBOizZGLlL3YPz30RF4sFcqKvpIqOYs= X-Rspamd-Queue-Id: 2B2C140053 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=DNWL+HfE; spf=pass (imf01.hostedemail.com: domain of elver@google.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam01 X-Stat-Signature: 7byfxd3wys9heu7spkmu7ixgyuieuudb X-HE-Tag: 1662023936-647188 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 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/