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 9D91BE93714 for ; Thu, 5 Oct 2023 20:36:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4EA28E0009; Thu, 5 Oct 2023 16:35:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFECC8E0007; Thu, 5 Oct 2023 16:35:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9FBB8E0009; Thu, 5 Oct 2023 16:35:59 -0400 (EDT) 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 A8CF58E0007 for ; Thu, 5 Oct 2023 16:35:59 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 875201A0484 for ; Thu, 5 Oct 2023 20:35:59 +0000 (UTC) X-FDA: 81312564438.11.05D3DBB Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf20.hostedemail.com (Postfix) with ESMTP id B501B1C0005 for ; Thu, 5 Oct 2023 20:35:57 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ruomuc5J; spf=pass (imf20.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.45 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=1696538157; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fshyiHld1iaT92zV4X7OYvw4ri66Z9VzIvd68VZWy7U=; b=CJxPRvpGrH2l/egj8EFe4ehlUwt088h+BnkZJaQroBn5HYEx9X1LCPuFQL7DEFfwFAH6yy yXH4zykgzYClvHqzchKsYTBAf5F/RFuf5ZWNHRUMf/SmUfxg73NebDrgi4WxF/5BO3YDnV 9bEvSdPbrTlkyV1EE0SKM3mua60MhM8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696538157; a=rsa-sha256; cv=none; b=F5mGF+vmMX7CZcePN2cy9WiRz77oRn2NOsiC2tj2UDqfpkrA/eoa+Uy8PMDWUhV+xZgirS NPuiPRjcxx9I+6vX+VU1FG3i/14N4LSOfLzkCvuVHUdioyDtiUndOo8wN4HazIkKrAjbZA 9YVR2ZOOL33UVaLrQGiwejv0iI3+Htc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ruomuc5J; spf=pass (imf20.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-27758be8a07so1126575a91.0 for ; Thu, 05 Oct 2023 13:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696538156; x=1697142956; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fshyiHld1iaT92zV4X7OYvw4ri66Z9VzIvd68VZWy7U=; b=Ruomuc5JOr3f/PfLgpG9gKO387oZEjYhXexbp9/+mCBnSQ52DevOr4o4kx3rUkmChP wf/U3uUBQ23zO6/hf4KzJ4h7t/hd9PYEW4kgBBWrzjktZlVoaxvIqrzTSuPTg0PjDt0f s3cJXVWbOWuQtzbaHmARjwAfqq1PRgh9J4Fp+PbGqzgOzTwYZIVUchdo1xSICsSuwFWK xRBlWPLWlMbjjE1OJMvAAPn2oxMoObc4NnnnzHCig3T/wAreQa/o3M/ZNp6FtFUWzXJ/ 3nYZOER4S4tKzXum/NINszMpjDAuNWjOKIdli1fG5BFYO3zsQv0f6f5WMSJSWn0c8Ih1 XmPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696538156; x=1697142956; h=content-transfer-encoding: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=fshyiHld1iaT92zV4X7OYvw4ri66Z9VzIvd68VZWy7U=; b=Rfz1x8PK3pO5/nBspjqWhEqP2d1QeMSvQh6rMNO6f0gNgKNh5WLpj7ZYICoG0e5YN+ MIQEI1qupmOxDOCcj6r9WS+Jut/DwMCAAVrRkmqT0xt5SzZTRQvOGGYnR7g1EafbtJMI yMHVzdLV7kEyVr+By2k4dLQhyjXbiE5el5b6/2DZUSi9F3Zjxs2T1WhI969+b/PiD+Er 7WJoMoyhFCTiBVRUZZbKDOzfqFcQXTspYTqw4HmOhzWaMohYyuRRorjvv+gVO0MbSEfh 1ouY+Eg6PvAaD/9GrLtDouMdLYIFa9ODr3xcCPvbzJGNeqd1f9l7CqL0hEvejd+2SMAV VEuw== X-Gm-Message-State: AOJu0YzXvD4GEsgOzac0reJm/n8OJH8TmOI2G1HU5iJkJb5pD2Vvx5Ng 1ljQBdsTJBb9g1eY/734wAdtPS+oXByQtvEHKqc= X-Google-Smtp-Source: AGHT+IFBps+uCydflmoKIvVDVKyucI0EafiSnozTWDbyFVQCmCqmb87LUDvC8TqhYFtwK9pTKNpcY4CtSBh8QQ7CVXA= X-Received: by 2002:a05:6a21:6d9b:b0:14b:8023:33cb with SMTP id wl27-20020a056a216d9b00b0014b802333cbmr7689179pzb.11.1696538156295; Thu, 05 Oct 2023 13:35:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Thu, 5 Oct 2023 22:35:45 +0200 Message-ID: Subject: Re: [PATCH v2 00/19] stackdepot: allow evicting stack traces To: Marco Elver , Alexander Potapenko Cc: Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Oscar Salvador , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov , andrey.konovalov@linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: c7de5ji6fwifgayaxh8zssuxjz33qud3 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B501B1C0005 X-Rspam-User: X-HE-Tag: 1696538157-87622 X-HE-Meta: U2FsdGVkX1+o5U+ShUJ8hJeLvjefXtXRMSkcjYGZvDmoBDtcLQPimJLIWf60bcSxXCj8/LDGfmFQxGANxrNwEcAA1x7qsti5G39qzmrNcenHmj+WhXz0elpuQRQ2uQZvDFnN7xmHV/OIQp4vQTEJoMknbPE0SodPm76J4SvP6atEwb29l+bJUs4W6YgMj53I/Mbmnt2IIRhmxqnxX2hoExi22KTh/94Y/8+RXdfCvz5fUflRdyHbXVh2yPR24dv81Z1rudCWy76vOf3280cAQOCQYnXaFyehHG/nsaHSf0A0UFmAr8HiIY8TUPYCmxNNidmOvGG5XZewLzXArambU/MwKWNtxjYVt/bEvjY230BxDwoBKaN6ZOXyZZLCco3QQoQ0NUz56FOBvOLzcceZtPcZMAu8j/PciHTO5yXfsZEg8P666OHkqPmjvutLTlmKW2nAZLD3QXkkseEitlAofjcZmBQh3oJJhUD364DbiXj+Z2t5TAr321t3+3YvcGz22x2Tg7ItCC845QXzIiskx31PVJo/5xfazQEODA9Jqu60DZoTh+pZimXYxfhcjdqK78ezwYBZbXxA6A7QRxpzuUgY9tARlui6EWxJmqChJ3OXfpMflWGlSMIY3TW2n0kpgCfuOYYt29uQ4X9FxWBdY6P1Wepd61vsAxlhus/CrKhWDqPxgzUvtSHCQ+vxMoWK7Dcsp7wbILAxNOfs/1Fk2S+B+uL4degcNdbgGDrquo9CV5QL3J7WzNhiaDUXUr7pt7joJ+wAI/kvdBb3LFAOlh6N141LSw6edxPnpfmCVCyQLBPkCiUlaQqQ9V21IPO6X8XdLYC+GIDJx6DTWpQDk6Oj2k27+o3+aWFbDzBKFswfIx9h4mYAVr2JrgmdX3Y6P/kl82k+47TgL+pCpXXkUXKcVebeB8wLXxrgK2pukCuEYFjXSxwSYBmS+cjA/tiToE8gr514C/bflg2OgK1 CEDuoKZi JuDV9Ze5PUfGK4rqUzxlFLGqPAEcovWF00IeekYaTmJd5tHakyEeJ6LJokCKFAC9g0AU/AoSVOgidzV6UesB1FuLlJuwNXTI28N7JRzcsTEO3B70gg8IzUlglJQQGx2iNCCnZWSiU9ZCUtI17+Pls1F18uc3IiyPkAsY899a2C98EW8yKUbPmIz1c2xJmnxJ/c+q6M+vKPieY8E/IspAcfnGzokLoSRRPGh6C5KhiIBlF2tBiyaC7EFf3VCjI9E6VQ7QU1fH9p2QwXjtw+2ZHaM/EI/vaC1GiHrU62TXMQZIB9ec+8tm2hH2D9y3rcyRC5DyXKZOA1E7A8ZKNZYzr/4Ia8bHZGRJkGc3bopr9SCHduMB/KKGMXweh2g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.004103, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Sep 13, 2023 at 7:14=E2=80=AFPM wrote: > > From: Andrey Konovalov > > Currently, the stack depot grows indefinitely until it reaches its > capacity. Once that happens, the stack depot stops saving new stack > traces. > > This creates a problem for using the stack depot for in-field testing > and in production. > > For such uses, an ideal stack trace storage should: > > 1. Allow saving fresh stack traces on systems with a large uptime while > limiting the amount of memory used to store the traces; > 2. Have a low performance impact. > > Implementing #1 in the stack depot is impossible with the current > keep-forever approach. This series targets to address that. Issue #2 is > left to be addressed in a future series. > > This series changes the stack depot implementation to allow evicting > unneeded stack traces from the stack depot. The users of the stack depot > can do that via new stack_depot_save_flags(STACK_DEPOT_FLAG_GET) and > stack_depot_put APIs. > > Internal changes to the stack depot code include: > > 1. Storing stack traces in fixed-frame-sized slots; the slot size is > controlled via CONFIG_STACKDEPOT_MAX_FRAMES (vs precisely-sized > slots in the current implementation); > 2. Keeping available slots in a freelist (vs keeping an offset to the nex= t > free slot); > 3. Using a read/write lock for synchronization (vs a lock-free approach > combined with a spinlock). > > This series also integrates the eviction functionality in the tag-based > KASAN modes. > > Despite wasting some space on rounding up the size of each stack record, > with CONFIG_STACKDEPOT_MAX_FRAMES=3D32, the tag-based KASAN modes end up > consuming ~5% less memory in stack depot during boot (with the default > stack ring size of 32k entries). The reason for this is the eviction of > irrelevant stack traces from the stack depot, which frees up space for > other stack traces. > > For other tools that heavily rely on the stack depot, like Generic KASAN > and KMSAN, this change leads to the stack depot capacity being reached > sooner than before. However, as these tools are mainly used in fuzzing > scenarios where the kernel is frequently rebooted, this outcome should > be acceptable. > > There is no measurable boot time performance impact of these changes for > KASAN on x86-64. I haven't done any tests for arm64 modes (the stack > depot without performance optimizations is not suitable for intended use > of those anyway), but I expect a similar result. Obtaining and copying > stack trace frames when saving them into stack depot is what takes the > most time. > > This series does not yet provide a way to configure the maximum size of > the stack depot externally (e.g. via a command-line parameter). This will > be added in a separate series, possibly together with the performance > improvement changes. Hi Marco and Alex, Could you PTAL at the not-yet-reviewed patches in this series when you get a chance? Thanks!