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 9EC55C3DA60 for ; Wed, 17 Jul 2024 16:50:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E3F06B0089; Wed, 17 Jul 2024 12:50:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 194A96B0092; Wed, 17 Jul 2024 12:50:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00CFD6B0093; Wed, 17 Jul 2024 12:50:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D4A686B0089 for ; Wed, 17 Jul 2024 12:50:39 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8A1771C12F0 for ; Wed, 17 Jul 2024 16:50:39 +0000 (UTC) X-FDA: 82349833398.05.E01C0D1 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf20.hostedemail.com (Postfix) with ESMTP id 9EA101C001C for ; Wed, 17 Jul 2024 16:50:37 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=FCTFcBiS; spf=pass (imf20.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721235006; 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=GRwsvdaZVXEcKOPI7Y0OJEITVG+ZtOtBwrLMsy/wr9Y=; b=zMiA99kA3qXt3w2j87lcy9Yxw7+t+ZsfkqvjrFk7cnrvDjnoDTSXreOD/+R3DkaXcvzXdh Z00d8IN2LewtvazZVwo2oUxozgFQ+SgdviGxPn6Mrx51a9bYE5e93npjK08u4e+b1Kfa+v lkVFriYkaYH3V+xq5zewkFROQVB48GU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=FCTFcBiS; spf=pass (imf20.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721235006; a=rsa-sha256; cv=none; b=b+AJvncTwp+whqpHiNCwoZsIXJqwvtsweuvAQzoi6ZrGo2WdqDFsWY0Jr2a/OGAG4KI7mW lG9aREfDLaJWbDiqXaUFqgvXg5AUmYyxzBPZv72fxUz8+l4Xl7mZ3zku8jOZUsykFysf+4 h1OT8V0pVptCctzulSliqHPjq1WLxIM= Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-447feb144dfso38349171cf.2 for ; Wed, 17 Jul 2024 09:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1721235036; x=1721839836; 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=GRwsvdaZVXEcKOPI7Y0OJEITVG+ZtOtBwrLMsy/wr9Y=; b=FCTFcBiSpaVJeYA/qFywVWkpKt3f/LwdttoeJjcNe0sw0RiX/wzZE+8iyegFf3ErjO KqEkNPSUSwckUhuzwFjeTi6NHpim9nowSPy7pqDbSGukoCafKW6HxGCfQdDVrIA/Kkm2 DqoOIWZLM1VhBLp7D73+1JOycwWIYhMkiFtD7jT4G+r7elxENXQVsUmpgrdVI+YQ75vd 2Cm7lbjoa80AXys3Jr7e0vaBzXOMqrryy9Ce4EC3u+QPWhCLdyc9/8XYjmSQsydshgnC 0ijNnwTt0LX7ezKZVDEAxiYfh2c6OJETkDFHsqoeEwS3DaGCEJi4uAx5xDIoob75YMwM pXug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721235036; x=1721839836; 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=GRwsvdaZVXEcKOPI7Y0OJEITVG+ZtOtBwrLMsy/wr9Y=; b=GeA5thGv1A9yGRtsbkeuQ5E4R3JJEThZOiB6C7q5YRmGf+zIR28QvoTeHZ7W3aetEl VulJVNyVQOOsQfYVya9fwZFyPzOq9gpoRB9LadKmEGkCgSTFjEfk/C/MU0AVM+zinTch 8SbH9Z9zF4WZv1Jq4UvouQbSHARNnSwqEJ/5dEiBElVHRgMPQFMyVGRTc/qQGOXlq1hd PDUkEvCM5z5hulgT9/DnfsT28yGc7GOD6jN61ODlbXAK2VEoBaQ7KzVkD2HGIuBLjzRV 5np/zswdz5CnKG41EUqN2Oz/bCRSsdNTszwrDYGnwVCOwFMmJrkEKBhpRTYXfg+9h6JX wDVQ== X-Forwarded-Encrypted: i=1; AJvYcCVMmqDS2F2LbX7AnIans3SxiyaPBaDK885Ygcl88MQZQkPberPo/zlqmvpvpEFm8VVcBspD0uhsH7GbwDrSOciV+JA= X-Gm-Message-State: AOJu0Yy0T5zT+YF/pwK2tNk8EoKNdSZ9XEfkhD1BSSoCtl3UDqhBZ/6w Bptc/GkHuFTvcES/ZhddOng845u6l9MS/FcWhZ2dTjhvglhC/ZTs21wFQgUhIKdG7JkOeMNBrpS iw5pjZP1RDG2DSi0+bzn1/cK/BRRtjgRCoPBCVA== X-Google-Smtp-Source: AGHT+IFxQYPCDcrmSsyEadwMoGGdL1siJDY+QJ39nyNeIqqsU+jt5WPPcMEoRxymnj/mknxyDZShtnwVgxiWZDNF+7c= X-Received: by 2002:ac8:58cd:0:b0:447:df1a:d973 with SMTP id d75a77b69052e-44f865f56c7mr30031041cf.38.1721235036627; Wed, 17 Jul 2024 09:50:36 -0700 (PDT) MIME-Version: 1.0 References: <20240530170259.852088-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Wed, 17 Jul 2024 12:50:00 -0400 Message-ID: Subject: Re: [PATCH v3] vmstat: Kernel stack usage histogram To: Shakeel Butt Cc: akpm@linux-foundation.org, jpoimboe@kernel.org, kent.overstreet@linux.dev, peterz@infradead.org, nphamcs@gmail.com, cerasuolodomenico@gmail.com, surenb@google.com, lizhijian@fujitsu.com, willy@infradead.org, vbabka@suse.cz, ziy@nvidia.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 3ua96e6a9ajicxhjhqdx47sh7auutjax X-Rspam-User: X-Rspamd-Queue-Id: 9EA101C001C X-Rspamd-Server: rspam02 X-HE-Tag: 1721235037-534253 X-HE-Meta: U2FsdGVkX1/BIIkXx/hMVZFFw5lVYu5f1YB9q9sTQAyI0aMYxRRyqJVIY2zfqewzHww228iUHeZXuVdJAPXa9zlbo/KpWXCpW57h/HQJXkUOq+PdxRhbpY2kpbk/CqneKi26dqykfyzjh9njNCXpa8uTvVwNivaPvOwsAnUTtw55AZLxgpkYe/jX1Md0JtN59gC7aQlHPDzuOTZ9DWkLcOIuzC62OzvDHyipdVdncRWXWcYr5e7Bcg6N35EJJhazhFD1ylWi52agz4Zn1SzWIEXIZ/11F52WoGbFvjQrtvBJGI+PqcJCf5HAeeZNew2UoY1FU5vp0B5NdgkKemYxQyRELNcVrQ8LbtO1iqxEPpoH8uhGJUN5wtAT9bMJ6UP7SAaPtp9xhSeuRVpwwBRoWqnAnK/8Me6KcIf3FH/0mVZZ3Q2ZFixls4lAGOR/mE2JKMINp0MLhDTvGlZI8YoigOiwxw+pQcfC+/Lgt4x/pOWG/D7baHHoJXaUQuYycUhrifDgKWsXdqEBNA6focIfE9i9fnZaVUb0o2TVsQ8gQhu5JhZ8P3pRJr0QMLgk0r1tylMO5LcwHlcbxsCv+xgj6zMQ7XYHtWQ7yJWFFFPjVp22JCns1vFEt/driKfepodS5zFDtGncRmUUV+eE2N3jXSrrHUgfa+t8jNRCAw1YPu2sQevpsD2VPR4vlwjtKgOpsTwBK0u3uNeT9oJGdKF6LZ7HA9XpxIoWID2kxPUjRq7aL+4PbSFgcpGDMtql9n5nC8gOHcn83PU+v1KhlYCzd6BkKewPr+wfPny2zsWJrWjECc/wgLadUGfxauSvMmjcMHyEGj/rO9II66oaKs2EJwVA0cVpKmcx5G5lSRz1UOMAOjJrIbAzYIMxs21XLOkBBQF5l+mKOaeRVxQ0b0hP1a0BVbcxmgn4Koku8CybQUm3Akl8Gf8NJXqsIm08lQ63q+eEr+EkxNig8IRl11d tOIcLdbU niCeWhIu0G/lMiouS0bwObyD6Yp5yt41rRL417nIbSjUjcKM+lkq1Mgp2RteT5DCNwlxY2TV96l4N67puGBgkAT/OKLbPBQmvTynPHwJ0f9TN6JDtRPMAdcHdk1W8UKXd7NbskLXHpH0qjfGMgTdyaPxLyYckvExlozPcZeVZE5zPWDUAU+LvSVcCMhgoqOZQj02r4Lw+9DfF8cOChA3ti+W07cgxdHd8ufpS 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: List-Subscribe: List-Unsubscribe: On Wed, Jun 12, 2024 at 2:50=E2=80=AFPM Shakeel Butt wrote: > > > Hi Pasha, I think you might have missed the questions I had below. Your > response would really be appreciated. Hi Shakeel, Sorry for the delayed reply. I was distracted by unrelated tasks and did not make any progress on this project. To answer your questions: > > On Fri, May 31, 2024 at 03:42:34PM GMT, Shakeel Butt wrote: > > On Thu, May 30, 2024 at 08:14:17PM GMT, Pasha Tatashin wrote: > > > Hi Shakeel, > > > > > > > Couple of questions: > > > > > > > > 1. In future with your on-demand kstack allocation feature, will th= ese > > > > metrics still be useful? (I think so but I want to know your take) > > > > > > It depends on how on-demand allocation is implemented. On hardware > > > that supports faults on kernel stacks, > > > > Which hardware supports faults on kernel stacks and which do not? >From my understanding, both ARM64 architecture is capable and also Intel FRED is capable of handling kernel faults within the kernel itself, other variants of x86-64 are not. However, my immediate goal is to provide a generic way to increase kernel thread memory on demand, specifically when needed. If certain architectures are capable of in-kernel fault handling, they could potentially leverage my framework to further enhance their dynamic stack fault handling support. > > > > > we will have other metrics that > > > show the total number of pages allocated for stacks. > > > > Don't we already have a metric for that i.e. KernelStack in meminfo > > which is in kB unit? If we had true dynamic kernel stack support, then the metric in meminfo would be enough to estimate the average stack size, it would still not show the histogram of how large stacks get. > > > > One more question: Is there any concern in making > > CONFIG_DEBUG_STACK_USAGE not a debug feature i.e. enable in default > > kernels instead of just debug kernels? We enabled it in Google ProdKernel. There is some overhead when threads are exiting, because we are looking for the first non-zero byte, but that is minimal. We haven't observed any performance impact on our fleet. Pasha