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 48953E95A8E for ; Mon, 9 Oct 2023 12:35:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C50328D0076; Mon, 9 Oct 2023 08:35:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C00148D0031; Mon, 9 Oct 2023 08:35:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC7488D0076; Mon, 9 Oct 2023 08:35:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9B3368D0031 for ; Mon, 9 Oct 2023 08:35:42 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 690541CA72C for ; Mon, 9 Oct 2023 12:35:42 +0000 (UTC) X-FDA: 81325869324.12.9654286 Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by imf11.hostedemail.com (Postfix) with ESMTP id 8F2CA4001B for ; Mon, 9 Oct 2023 12:35:40 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fcWek45m; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of elver@google.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696854940; 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=wOKyQdcpzYH1S2DyazYIOAoD7VFJ1kfohupYEjtWCjA=; b=p/+unu5IzPfdFI+UgwS+8Ol876A+YQdzsKIwg9JXoRBW08kGUo3V0nJcdGvVVWJC4aM+8o 2y8sPBxpegpzNasrpVCs6yfAdfN6lGpzkgyLHhh+qPN5NBofcUkbanVuUKJiXzoEIQ1eXL /+ao6xrC4a1qr20EIx5EvSPLgZoIIH8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fcWek45m; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of elver@google.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696854940; a=rsa-sha256; cv=none; b=E/bp1Nr8Nu5hDMnraw3ymQFgu1iuGVQrOtGUyH8qe4TVEaDDFxXYFa+C3iD4gISaamOWB5 jD5+3uqajd8isGvJcdxFZiVK1zJRdctxQ1w7zIshg4OtPbbZr31qPvlXsqUox+FpxAojoI z6muX4LzU8BB53f8v3in33079B3HM2I= Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-7b07548b084so1319096241.1 for ; Mon, 09 Oct 2023 05:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696854939; x=1697459739; 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=wOKyQdcpzYH1S2DyazYIOAoD7VFJ1kfohupYEjtWCjA=; b=fcWek45mNlRiLVqMzS6Vzxo7M3T+VL6H9s7xK/3a1b1/WNIo2ZPVSyoAn2fZEK0VXA Xay6kn4X+WvBwA3FB/HL15E4IcMdykrMS9McIUFg9G8qbX8QJBs6A+0pbtLj1bJcwTUI jDvoVkI8HGomB1XOsJwGZkYvD3xiJ69AAoFPVlgVH289lw+Y0+6LdVN5ZCTTp/m+HE9C xU9nB7K0uYmGBzGjPewBBaZYk6fQ5arxycFLYdtHtT3Vj4fw59XEnwQdIzKAp5SiH+Qb 3mZzfsxvrF6vk7nAt7FPVwVIi+/5Au7zybVs8RF4/WXF1queV9Br4emU2gZOtsKLY7TX fsRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696854939; x=1697459739; 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=wOKyQdcpzYH1S2DyazYIOAoD7VFJ1kfohupYEjtWCjA=; b=lBzz+nJFmUkq5wHnvQnqVnmJXbsbne9vuh9cLrGW5FTbachRf3uiFANIjAXU9n1biK 9U6EgPb56bdWQ5+BIj7TXF86zAExe4jXBsGVKH06His/6imR0K+hpi33uXOhwqZgHnTN R9zKUa8f1WgtYRJRLPifIlexBFO301dmy8DlaXKOXqPG7Zsx5mHK3fBpsuRaD1d9bUjH pi2Z7Ya4qgpKbo10M66xHohAmvA5KY8LRbZu6e18Rzzfy6YkqCvVzU8X0WWcA7CgLd9c WnYxunLISyQZz4OVZbOnHsRK6TPJYENJijlheXb5KQ6BUijV+YRb6+VD12h737yfDesT Szvg== X-Gm-Message-State: AOJu0YwPViE+FR0auZgrIjTlhzljnooy7mjuzHCRu7Z2lrx2B9eq/7rM i5cAr1QR184Mk2F+8g64Pg398pdxvRzeGc9M4V5Jbg== X-Google-Smtp-Source: AGHT+IEpyX0LBMZJRB6KI2ixkBt1XvV/E8Mxkh2tyDV96XdcIEKorle9qeJ5tkvEALrBkBNrzqtoEjdoTJvMRmuLNJg= X-Received: by 2002:a05:6102:7c2:b0:44e:98d8:c62e with SMTP id y2-20020a05610207c200b0044e98d8c62emr12922722vsg.33.1696854939344; Mon, 09 Oct 2023 05:35:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Mon, 9 Oct 2023 14:35:03 +0200 Message-ID: Subject: Re: [PATCH v2 00/19] stackdepot: allow evicting stack traces To: Andrey Konovalov Cc: Alexander Potapenko , 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-Rspamd-Queue-Id: 8F2CA4001B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: b1uphdpihaurj1nx4d7j3pdspxmzhhn3 X-HE-Tag: 1696854940-573176 X-HE-Meta: U2FsdGVkX18RZkqbuaK9HRExxCoRBOdAl+F9W1SGf80f7TVZX0oIaRppu3x/wgZIwO1G048T7h39Uv0jE48SJAizmvYTuWBK8SWfG2oI/CStSO4pD8iCP9K4c0PVhBoOvnRCL7QsmD0Miuo8Ldli/dcxridNIvWnKq4WXNAaPrJguJgOAKtoro4A2rZzzNJ8KQStkmrZAcM4C3XXbWWy6uoLxnezmjfP2G7mwLlSsiYhXbVRncEk4M/1UXtFHhDzDnAdVUr8kHj6LH+7gwuXNdvjNyvOxsKcX9zXksOKup2Rjo8njxHNVupBtGl6vWZ5HctXuGVeDiZSlqR5cafFnnIH0H2DbOIxRIepZjo98gI1UD+yIlh0gOnWUl4OQhuqCAMs4IvBvxJTWiqpSFEI05JUp9r6ljnsjVospf0Sa4wqnzE0hiev4yP1TSoCiEaqtJpNU43EQ00hNL0SlDWvsJXePz3KhFyM/g2UjAEhT+iYGxpoivILBilhulUwjbJpsmvVgXLf3dcmS9ZJbXGi1F6wqkdux+YQR66c9tGuti3cd8SOdkunVa05b5ZlQbd+i2sC9W1omOL7uux+Y2OhH04EQ8wYNRT2SLeuMYU6EyulKFEWvZXGgZ+x4Yl2KSuMFT2UZEHlFP6MeNTrzH1b7aSi2C33iSyjSZkfMZ6ZnICJNAp5WkP4FjA/334Ur34/951BGCYF+2JJa/Rm41mhx/8JutDujZfUbCHwe/8Ig/PpWbDjJM4YVGBHx2NTeU7Awp5oyCzfzb93UmbIi/82ehpEkXfAQue0JHtJTIiZGJBmM/QtHGS8rNel3c1LO/t8Fe+bCQQniuYeWVIrQgBCd41BeaUmSqeE4psORwlhAAkpYBOXr8/NgvQWK/SZzhIfcrjIB8DIof9wfZ2TLEFQzH7bXmrxaRdzLLPemBZm5KGZnafK8kcAYxjfKQNeHzASAwidz4a5UI3oYtRljqn i6f20TVX 7Jac8u9ot6yoQzDh4H8tNyOdkKuS1Tn0Z/N45T3H+wAb4ngiN/cIdtcMHIjnD6m0M4L42sr7euEWx566AZQekXak6PgWJraQYDpZSwUj5SLCWyUJdcbsMUoXllNf96ORNA5pZWvU37l0aOldyyHvF5uT7mcXeWoyB9ctjJR6L2wFVQFEyC7iD/c0gQP6ZmW7vtwmJUO5c4f4VTtf6xJIBaRaioXPLXLtfNdAk8EZjNU2YmrOpE++PE39Dr1a+qMZjeN9rRWPhxHgIdn4Xa1DTwBoXCA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 5 Oct 2023 at 22:36, Andrey Konovalov wrote: > > On Wed, Sep 13, 2023 at 7:14=E2=80=AFPM wrot= e: > > > > 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 depo= t > > 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 n= ext > > 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 u= p > > 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 KASA= N > > 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 fo= r > > KASAN on x86-64. I haven't done any tests for arm64 modes (the stack > > depot without performance optimizations is not suitable for intended us= e > > 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 wi= ll > > 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? There'll be a v3 with a few smaller still-pending fixes, right? I think I looked at it a while back and the rest that I didn't comment on looked fine, just waiting for v3. Feel free to send a v3 by end of week. I'll try to have another look today/tomorrow just in case I missed something, but if there are no more comments please send v3 later in the week.