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 5B991C54E58 for ; Mon, 18 Mar 2024 20:41:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B2D2C8E0003; Mon, 18 Mar 2024 16:41:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADC958E0001; Mon, 18 Mar 2024 16:41:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A4768E0003; Mon, 18 Mar 2024 16:41:02 -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 8B98F8E0001 for ; Mon, 18 Mar 2024 16:41:02 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4BA2A160626 for ; Mon, 18 Mar 2024 20:41:02 +0000 (UTC) X-FDA: 81911329164.19.B1E2477 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf09.hostedemail.com (Postfix) with ESMTP id 4EF46140013 for ; Mon, 18 Mar 2024 20:40:59 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=NNy5AYxq; dmarc=none; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710794460; a=rsa-sha256; cv=none; b=tYMcKpM4/eMGMbctH3iFpilNEB9aSdv7VkoMwJo4WaypkkHOgrDcOjCGvnH6SS3E9b6zTC pnbOB3nLd+dLQMQOUbjulA2wKKLAbruSeqoQpLTI/r2gA50QjSl1mxwS5I78zikD5veTjh xwNuNEtDuYLVQ1j1EM/xfUo/zNsy7wE= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=NNy5AYxq; dmarc=none; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710794460; 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=lcsPuv6lT3FkqIB/a/PW1cFJAME0eM3mffzMBZ7j8q0=; b=CKaaGfp0zgXR3iCImpL54rg88jIH52du0e0LvJJmeYfANvJI4leszQFg9V1+kawiwZaQKS DX07PA3wEeyG7AWF7KenjZs/MDiew1azCbRHVlVUjztmLuiDmWJFC15IwkADPdBQKCiFAY 314mR79Yi4E8/g5fdxsrjCwA+H60Rvo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D1E95CE0B61; Mon, 18 Mar 2024 20:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D26EC433C7; Mon, 18 Mar 2024 20:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1710794456; bh=ASewAmN/H3/b9cAvyrgmlDE+vLv+687YtUvC+KDcgsM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NNy5AYxq/SzYhGRPZyu0aqo8MrkgSqSKjawZ7u1Y9b8P22xkCOwm8RZkp5uIypwYu VLInFOpKPrGufAMPzfM1EbHECYq0dA5bmLQIvf29FGr0XEJC5xN7rykybzwRNEDswR B/2EqWIyLAXsRCaJIZkywTzpvjVcDYRdgqjZey8I= Date: Mon, 18 Mar 2024 13:40:55 -0700 From: Andrew Morton To: Pasha Tatashin Cc: 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, shakeel.butt@linux.dev, vbabka@suse.cz, ziy@nvidia.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] vmstat: Keep count of the maximum page reached by the kernel stack Message-Id: <20240318134055.c2f6b29bb6eb73ec93bf7079@linux-foundation.org> In-Reply-To: <20240314145457.1106299-1-pasha.tatashin@soleen.com> References: <20240314145457.1106299-1-pasha.tatashin@soleen.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4EF46140013 X-Stat-Signature: 3q6csr615nutcarxafzkk94nzdsbieff X-HE-Tag: 1710794459-33672 X-HE-Meta: U2FsdGVkX18ikYlxCoa9JycW/s4ilaktiAQF6/PWaGzESB6TMdq6KL3/1K+2Seq51u9CDcunWkEsVRg1dCFfmJJTCrbPW22D4w+PWih1Xw0j8kUBekSvtUz0xGFEBElWFRw/rMGQ8EdPOXA5Gi9wZJlRKdiRt0BUM5TefA5itPsrsV6cBTsV80WZw+xLjcUTQNcy8DoVkIuJUlHj3UbfDJWxwZd8WhJVmQ4tngUioIO8PooNRTU0+vTt65tha+EsrAKLxMLy3yIUfwBplnGsAbq9+Ox1sTfPguLGHyfIXEX9+UpoqdWtJkcbIJLyme917O5svNHpz168rktN/qXHKAT9TUUf7Da32IU4uZRH34gc13p9YH1aHxtgFUQAnwOTZOyzJsWeP8YsLWq4wf8F8tc9SmNj3WPS8GsiXPp1xu9S4e58S05L882ks/Uie3osTY3R/YyoPNfL2LnVBjMPMbA7wla3fJX9R8eHskC1A8/wTqYJZBRp8Fyls9q3el3NIfRsFBvnenV8XynVVSolQzQg1FAUY2f0XW0CMlWZbhnkw82ct7bVn9ZsCbzQ89CLbmxr6kiEU8SzkWxL0JT6nJKnsT+hr0CF+EZxv534z5fo96tqEyfcxOip8+5mXK+j2Bk9HuYxbozjXSW/aem8IeWVz3gccIuK3lTegstE179SK2g/SlQVga8xewCYojt3t3TQ+uWDw6HUbz8x63CIRorG8o+u/vBiZFFpgUDfqSj0S4Gpphg0NTPr0CwxtmS6Agn3WB/mT/EXWNiOaFr9XGQvAIuqhRoo5K5idc99ff347QXfyJhWSd7ZeMk3ZxoVX1O1CnKTrotWEMDZmFiVhZqeh2Q5ssl724lBh3lSu0Psgch6a4OynRPJK0vl3tktcRq4qKPYP9cndGBeZc5Nxf29oAFdCyjTzhOgwiCFOls= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Thu, 14 Mar 2024 14:54:57 +0000 Pasha Tatashin wrote: > CONFIG_DEBUG_STACK_USAGE provides a mechanism to determine the minimum > amount of memory left in a stack. Every time a new low-memory record is > reached, a message is printed to the console. > > However, this doesn't reveal how many pages within each stack were > actually used. Introduce a mechanism that keeps count the number of > times each of the stack's pages were reached: > > $ grep kstack /proc/vmstat > kstack_page_1 19974 > kstack_page_2 94 > kstack_page_3 0 > kstack_page_4 0 > > In the above example, out of 20,068 threads that exited on this > machine, only 94 reached the second page of their stack, and none > touched pages three or four. > > In fleet environments with millions of machines, this data can help > optimize kernel stack sizes. We really should have somewhere to document vmstat things. > --- a/include/linux/vm_event_item.h > +++ b/include/linux/vm_event_item.h > @@ -153,10 +153,39 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT, > VMA_LOCK_ABORT, > VMA_LOCK_RETRY, > VMA_LOCK_MISS, > +#endif > +#ifdef CONFIG_DEBUG_STACK_USAGE > + KSTACK_PAGE_1, > + KSTACK_PAGE_2, > +#if THREAD_SIZE >= (4 * PAGE_SIZE) > + KSTACK_PAGE_3, > + KSTACK_PAGE_4, > +#endif > +#if THREAD_SIZE > (4 * PAGE_SIZE) > + KSTACK_PAGE_REST, > +#endif > #endif > NR_VM_EVENT_ITEMS > }; This seems a rather cumbersome way to produce a kind of histogram. I wonder if there should be a separate pseudo file for this. And there may be a call for extending this. For example I can forsee people wanting to know "hey, which process did that", in which case we'll want to record additional info.