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 CBBFEC25B74 for ; Fri, 31 May 2024 00:15:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3816E6B0092; Thu, 30 May 2024 20:15:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 331636B0095; Thu, 30 May 2024 20:15:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F8B16B0098; Thu, 30 May 2024 20:15:00 -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 03FD26B0092 for ; Thu, 30 May 2024 20:14:59 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 791B0120BF3 for ; Fri, 31 May 2024 00:14:59 +0000 (UTC) X-FDA: 82176770718.11.05D7A68 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by imf15.hostedemail.com (Postfix) with ESMTP id ADD7DA0012 for ; Fri, 31 May 2024 00:14:57 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=XodTHfVr; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf15.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.210.43 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717114497; 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=YlITfRGBGkiGQh2yf2/+rH6KbsrWEjN3IQxGzASO3WU=; b=QQaQShssmqXfJ5TZysm+HBLWnq+JU6/Wwdq+2/yLaQQELHbzzwX42NeSKRs/Z6Qwlk6VNp rXfAm4cG6tq1EQFi3qIZRDgZkEM52YrozwexGi54OHJiqDF3w9qb81/uzkRne8LgFEKHWo +bl0nDaPRGeXs0aOD8YLjgwRpmCGHUw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=XodTHfVr; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf15.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.210.43 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717114497; a=rsa-sha256; cv=none; b=lk/Gyq3SEEdYpuAYeuGVzMF8Qyxvtfgtvd6lG3oeuRyUdwQajKh4Q47JWi8gY1gw4F9fd8 AbSBTX6Qo3/39lcDBfSWgQsKPc1mzWiPixM96XpEFj/mpf9xWo9dYcLit94qkdLgyAk/br XRrPQFzjx0ySobPe/LjOELMfQpGyl+g= Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-6f8d0a00a35so409700a34.2 for ; Thu, 30 May 2024 17:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1717114496; x=1717719296; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YlITfRGBGkiGQh2yf2/+rH6KbsrWEjN3IQxGzASO3WU=; b=XodTHfVrG3kHvKWIrRkXxcSaJbhyYrw3Yhs1uaSWcWsgxl+sxFu300qL6y9VYNL68Y UNTS6vcxTVaYSLTyUKNnTiCM19koZBSARG0YGJJpVzjKe1ESlmI4AqFlMr/Bb3pk5svw kHU82BvxuP7ONscoqOqAilq+YFycVH62NFO5REaFmdr1khPLaGdhdV/r7N3Jd3wAEDI5 4+Ec0P58AbBrDS6OGLIHPmkg/SYt987HzjDMUm4NSBg29VbjDZHiZ3WkTfwa4lrTdL2/ 5F9PUMdI7l3GLPrRzeB2pJGJfMdKMr4bAS76Vb27ouQL4dK/mDBQfHNFzejUsB1iGDK5 etLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717114496; x=1717719296; h=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=YlITfRGBGkiGQh2yf2/+rH6KbsrWEjN3IQxGzASO3WU=; b=YK/Fb9158ZmYJS+Zm9vdMu7utk6Xfb3ssDpQn6ubOQ9w6U/tT9UyvrnQU67feUOZeP wQTj/RQuFPPjulPl4jZ3UBsJiEpqHtLWJ3uHhvA3lZDCZxtxB+1Rxt/HJBVsWJzOyqNi AHNv8zX5KmdKXIsYSTkVXrNbk3ES+o6eV3fGd9putjeLz3JDd0xIDUgQ1OB4/1RNa8jK 3StSHoIvVaCNiLqnFYOVZKQT/0CrmN846oIjQ2QQ1y/Begr+AOsOYeK8Sld0kzF7Mhzz xZmsu5Wl4XHalye3gPvNhsHHWOV1k2dI33ott3OgFQSiwlOe4QJpGjcZR2dzyWwzVpZi rsOg== X-Forwarded-Encrypted: i=1; AJvYcCU86fJP4QqoKVL7YeaH2QTtOX+F8lbVtruov9UIAKHL7geaEfKR6a+OWyocegcplvWWhA5/veL+OGTdxEwpniKVNLk= X-Gm-Message-State: AOJu0YxrXx3fTLtGY7LECz64lbKZAFBQlpOFHX4dB/rWV9gxSZxecrqO VKpwwaS6Kxs2t2/Ogqb9SikHhuJoHl/vYgZ/xPgFdE2xQPKRvYE5c2/AWAbf8aiF5z9V0nS2b5z g3uaBPdT6whbQrYyc6pgyW8pqsh60Mh7kWDtDvA== X-Google-Smtp-Source: AGHT+IHIuwRQeRk5CYGQyxuRuiWFvJgO1VzcacllnlVILGDdy4DHdL8jJjRKfKHzE5KSa34bYlFWdG8b8BCrZGY7GeI= X-Received: by 2002:a9d:4e94:0:b0:6f1:17ef:ef11 with SMTP id 46e09a7af769-6f911f48505mr375247a34.22.1717114496660; Thu, 30 May 2024 17:14:56 -0700 (PDT) MIME-Version: 1.0 References: <20240530170259.852088-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Thu, 30 May 2024 20:14:17 -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" X-Rspamd-Queue-Id: ADD7DA0012 X-Stat-Signature: reboa33zyntewmhspgfa54au4x1hu57p X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1717114497-590986 X-HE-Meta: U2FsdGVkX1/3LkapNA/Aw8+P3QGV6gwGGVsxEhgbFhq+xYDQVWI/ny9KeO8H7t2zNaoGjE8NFXRl44qApB4b0KJsgckGWHFe264pj7Tu2KwE12i3Hhnb7BYTTuvIyuzRT6koPDJmd/IwNf7CvdNpkRpIPHquCz/YuUvYsXvq6q2lQ66hXyX0HZQS+ujIJ1tRZa6D6ru17rjor9yOOzZcWV4L0jzC+ae0pqUgg1TM+u+4GWtb70xisvTmViV71c5iN5M/p/MwQvjLrRQbvX1+xNpzUaOuB9R2hFqX83lPVyG/7QLIlqOkKBjsRduz4C7aLUmqQ3v1d677FEAy82WWhmcyBIWtX9LryXQniPUh5h8HaEKZ9fDXiF+Lp5BeypwP66eU+t/H2CP+y4bqOx1wNhEJJbnRL/4VkwGMioRC2puldMiK6madk58OFHZ1BiXkP+JQ8vCErb5LBn2fc4DtuRC2rRYYjUc1CZ/kP7FGrviRKfoxAAtzhhB5jwR257rbXzTU9yGP8VJl10sOrXqRR8xl1fFvliWjS6YkXJ2DcQfb/LlaCTz1hEv8bDOd0ch8r0Ft1uFlSL8rsNuQeZxMeKA5mshMCRr49wBOaBA+99BQiJxwbPD0J+PEDeiRD52mOmFNPhYgUGZgDbm1EUafgWb1LE7J1+r9V2y5fPVQi9lQKE0knRdj2c6xHCNUG6tEWjrVNzFoWmo/VWWudBoXFugW7tA3lIY8U++hPT6e83HsLasurw+V2TkFvrV+Bj7ojTQK1F1Va9dkca21pNBqMNNeV4qwBk7QPz1aiSF2xqaVU3DOuuq2O9u5M0EI7v/cnzI5e0mdsQM3+3vrJo2oo5zMge38W7B+UaItQQ1iJdScdbh1ebmNrxYZ5MagdvdxmFIr9w8f2cctZEtpMuvDuueBZqrjIPaf+YGoxaJoiKXeiX5UPelqNdS9LlLFsD7p2F8DLLDCZ2EV9HbB2V6 eBZSlez4 M/BRWXgY+RojbjIXPZbF1jPA0Pq1nwnELkdSYa32m/Cgd7h0HBgDoiPzNQhnvxxRR1QkvubknllukwPd9K8/lZmQUFjE5insM82Yy39Y26QaaNnPYayyMXv2Bm+hV+q7F2H95gVpg+jP6c3RURH1hJePA87bv4TGAN0lTqrfLGkWnenRGSrE5F2hNQRMXA6lTI6e9wylQ2ZsVgcHATg8tAlxVfgnYgIWo9Qoh8+JKaLsjECsScbI78jKGMOhp9oZxNOsSjySzlroAatCvpNQefAM8B9Kb/UVqy0x/ X-Bogosity: Ham, tests=bogofilter, spamicity=0.003880, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Shakeel, > Couple of questions: > > 1. In future with your on-demand kstack allocation feature, will these > 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, we will have other metrics that show the total number of pages allocated for stacks. On hardware where faults are not supported, we will most likely have some optimization where only some threads are extended, and for those, these metrics will still be very useful. > 2. With on-demand kstack allocation, the stack_not_used() needs to be > changed to not cause the allocation, right? This is correct, in my WIP dynamic kernel tasks RFCv2 patch series, I have an optimized version of stack_not_used() that uses the number of allocated pages in the partially filled vmap to determine the last stack address. > 3. Does the histogram get updated on exit only? What about long running > kernel threads whose will never exit? Yes, for performance reasons, the histogram is updated only on exit. It would be too expensive to calculate for all running tasks. However, it could be extended to be queried on demand via a debugfs interface for all running threads. On machines where jobs come and go over time, this histogram will show the actual stack usage distribution. Thank you, Pasha > thanks, > Shakeel