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 4F38CC4332F for ; Fri, 3 Nov 2023 21:38:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E373440147; Fri, 3 Nov 2023 17:38:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96B588D000C; Fri, 3 Nov 2023 17:38:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80BE9440147; Fri, 3 Nov 2023 17:38:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6D9738D000C for ; Fri, 3 Nov 2023 17:38:10 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3252C1CC2A7 for ; Fri, 3 Nov 2023 21:38:10 +0000 (UTC) X-FDA: 81417956340.06.A1DD4E8 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf19.hostedemail.com (Postfix) with ESMTP id 6FFF21A0012 for ; Fri, 3 Nov 2023 21:38:08 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Qq71/07R"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699047488; a=rsa-sha256; cv=none; b=tR9TNR/tvYjISYu7jUxRUL+M0PRRZPhaVN1cSuykSaXrkdSNAXKioxps58tGieVDLXeP6f Cq8TPRf+v6a5bOF2FI/YaYoIJ3grzOS5B4T46ku/npat7nA2i5lOWcpz/LlGshHWyxgvLh 3j70dsfZPc53u8W72hqK0+aTf1S7GhE= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Qq71/07R"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699047488; 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=TwErFEOvRqH77tvd+byjAioyY68nFad6bltFM5K+5yM=; b=dfwW5M0Y8Cm8hMTaAW5PqW0pHOtPqaFT5YJ2MV5EctGWoLfYabhz+8M7IoRvBMiERQaVl0 nW5uogFr4pkjgEeR2XLHZu9fGgymcylml8VhCKjlV+yRnngMo8sMXT2XAu0VAhqFnVkTFx kznSADq+sRSLl7ybEDXazctxVWrJUtA= Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-6c396ef9a3dso497374b3a.1 for ; Fri, 03 Nov 2023 14:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699047487; x=1699652287; 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=TwErFEOvRqH77tvd+byjAioyY68nFad6bltFM5K+5yM=; b=Qq71/07ROBcGEIVL0NUx7FDpfi7PsjJfA3+Q8i2Z8x6ydWVJgIXFTP+ChdyUXJqqnn TmRjEeujvH+iZuAhUdrHj+IjjIE+Hh7UCs3wFotOPOtQCCnTR8mJE97YUGaTgoi6FoJ5 NnGanC+gWmyED6sIitlaXNnV2vN8+2pY0lJ5BHRXQnRNjJbDg9lncbZtDg2/bmIITOYf bxXcuTLpB3lKgfDNDbWqb0DweAgT5FeSIJr/2MgT995PlcE1tGVUV7K+YNTRk5S3AA/7 Xpk6HiJdXXPyHFbqaZ8a9DcezgF8wbl5oTtC6MbOCPc413jn5SIKQfsd8fGSIcxQHpjW eijg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699047487; x=1699652287; 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=TwErFEOvRqH77tvd+byjAioyY68nFad6bltFM5K+5yM=; b=WSgj5dDRriC71t9RcIUc9L5YGrDvtn9JYZV6lI5rdrFmuN1iYSk3VQ4syoW5OgVnHJ gND/rK5rsfDhbNXZCVa/7+ON7h95oDNoOGmRlcUzE9ZswlEC7Q4cPzgypqEKywo7fU1K uC1Ato4ipVmyHN9/f7woNR6vv3lY9jteFACV0uYQyfb+MCAVuPQtfUe1oPPnLLjBPRN1 nArSMh5TU2kJUamRDNDmTF/9lDiz6VrWkHshhUrr2pWwoQOj0SoH/OHcePbliBkpU+7H 8J97vKl/2510qYiF7FD/E75A3JByWAiCM5tyqLh8kiX900HQD8PPv8DJdNnEg6oN3BFq k68A== X-Gm-Message-State: AOJu0YwOKdnh11Hbd9gbG3+ej/jvUd48uflttAI82tOslC5f1u3b7y6k N3uUTeI7kT5MKV8ROWl2f1KIFY6xoehwc6ypjHI= X-Google-Smtp-Source: AGHT+IHOHpCahBHRq/RlAePjwSKPXDC0zfTu4rDCG67yPtPFnTK2BOrf0rCbvsvxxn/F4CJCOpY5+SSFT1/nnzpQUT8= X-Received: by 2002:a05:6a21:a5a8:b0:15d:d73e:e398 with SMTP id gd40-20020a056a21a5a800b0015dd73ee398mr25322907pzc.16.1699047487145; Fri, 03 Nov 2023 14:38:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Fri, 3 Nov 2023 22:37:56 +0100 Message-ID: Subject: Re: [PATCH v3 00/19] stackdepot: allow evicting stack traces To: Marco Elver , Alexander Potapenko Cc: andrey.konovalov@linux.dev, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6FFF21A0012 X-Stat-Signature: c94mysagef8ttmsyuqoztj1t4cdiu9u1 X-HE-Tag: 1699047488-984453 X-HE-Meta: U2FsdGVkX1+c6slkbnlyHMZDNE/P0d3pN+MTL99EAurnDYdkYMMNETSrPi/lqM9wd44Y3/2XIFPDvrr70JQ06NGX2XdlUCVIfhKA8cYOl1uO9uQeRYjZ1fmgd46p2BujgnxZ2bMaZYBrPieLZcuAiqnaZnCcdL2RI3jeIQvIOgClKdLROQSpDY+IW3Fd4F6DZfsACeqSuXYBtzo+WDpEHty9IhmdVr8bx7FmQMExeM/Xf86PtwnFhNvpMlZa2ezMbOlBjGEw/fdtsVkKOcztuWwyQ8g8Ad/jOqnCV215kQHweMgf+jcnmH8T3x8/zDJKCqvV702mxckqwKk+UzLiAzqDWqxOBPWkHwmGK5BhTe9RRFzbCiP3C8bR+AiNd/DTo7WtxoMllRjVG8Q07h08I8UawbUVHB5vlBHMebtVF68CdjSellvugTUoAvLSg7I7KxdEVOJZy4dZzwsnwGjB7GjIGU6dP5FRet9Q77k9IMex5gTAvltQj/bVvsdqzlYjlbaL4fXse8rY/fj68Bt2hMJOoF9bDdpAwC3mxZcPoYRIIu3Gq1VTOvG+Grg6Qa4N5h7wsz5ZKrBsCBZ4eERFDPy542mLpaVisV90j9q7P9efOy9wMjvnWPEHPvouGx9DNIUOhQTo84r5YiIe+3lzihaM7I5IGbHbxOpA5HmvJFn9JdzfJWdiIRbkhLgCi8Zuo5XwGiVmX55HOFk9M6K20uRQtOF7ikuAJiFK61qtqADFULDU/ioNqsuR/i5WAPcuDFouaBURityd+p7O6i9m7TqdiSptVZkYIMoX6WvENJ0peOAuKZ3E/MrpNdbhxJsHiFxmcNSz1s/YYEhNSbyHHumHqwjl5bGsJG7ljgCd98pLinVQDv+DNlwcnJ9WO8dj5UtjUj6PuuIrQSpeXrTEVyXuEFeL+reMFOja89yFsKMBlq5t9pX+sHR1Cqb0TmGWOKz8c4AL1qtnrekvBBx G0Dks6Q7 T03PldQQVMcIXQlSTQW4qDNHPNYf97F0aJofqU0IRNkeuYGUpPRcx6WW4MVAjb0EL/4EcYEam1ZL26lXSdmtwqcLMKhz5UqtfTn6eYzB6DocFw3yRKwLiHUsYX1C4h+Tqy7iWDH3ZB8sZMKA4k/jP9Th7bNN3QuBX9FqebOwst4Y5qOSzC6wkU/qFG2Nb/nys4q+sARbOzanlj+BV/Lk+d7STdD+2TDixJUGu8d4xCaRwPosHYrr8A8Fr0YgzWwqp2UL7noJS+/uNkj//4fzKkWmTZ5LO/YRTrk3tw7RlvBNBLXWlW1awW3yG3oD+rxLwlq2Orm37Ulv+8ZZaMORqyOG4Fcy9I1m96i8n3/7NJq55i7M2ClVOyxymwiIZHMxbnYyu X-Bogosity: Ham, tests=bogofilter, spamicity=0.000244, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Oct 24, 2023 at 3:14=E2=80=AFPM Marco Elver wrot= e: > > 1. I know fixed-sized slots are need for eviction to work, but have > you evaluated if this causes some excessive memory waste now? Or is it > negligible? With the current default stack depot slot size of 64 frames, a single stack trace takes up ~3-4x on average compared to precisely sized slots (KMSAN is closer to ~4x due to its 3-frame-sized linking records). However, as the tag-based KASAN modes evict old stack traces, the average total amount of memory used for stack traces is ~0.5 MB (with the default stack ring size of 32k entries). I also have just mailed an eviction implementation for Generic KASAN. With it, the stack traces take up ~1 MB per 1 GB of RAM while running syzkaller (stack traces are evicted when they are flushed from quarantine, and quarantine's size depends on the amount of RAM.) The only problem is KMSAN. Based on a discussion with Alexander, it might not be possible to implement the eviction for it. So I suspect, with this change, syzbot might run into the capacity WARNING from time to time. The simplest solution would be to bump the maximum size of stack depot storage to x4 if KMSAN is enabled (to 512 MB from the current 128 MB). KMSAN requires a significant amount of RAM for shadow anyway. Would that be acceptable? > If it turns out to be a problem, one way out would be to partition the > freelist into stack size classes; e.g. one for each of stack traces of > size 8, 16, 32, 64. This shouldn't be hard to implement. However, as one of the perf improvements, I'm thinking of saving a stack trace directly into a stack depot slot (to avoid copying it). With this, we won't know the stack trace size before it is saved. So this won't work together with the size classes. > 2. I still think switching to the percpu_rwsem right away is the right > thing, and not actually a downside. I mentioned this before, but you > promised a follow-up patch, so I trust that this will happen. ;-) First thing on my TODO list wrt perf improvements :) > Acked-by: Marco Elver > > The series looks good in its current state. However, see my 2 > higher-level comments above. Thank you!