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 E39E3C54E60 for ; Thu, 14 Mar 2024 19:29:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D168800DC; Thu, 14 Mar 2024 15:29:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 45A69800B4; Thu, 14 Mar 2024 15:29:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FA8F800DC; Thu, 14 Mar 2024 15:29:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1D35E800B4 for ; Thu, 14 Mar 2024 15:29:10 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B9C1B806C8 for ; Thu, 14 Mar 2024 19:29:09 +0000 (UTC) X-FDA: 81896632818.13.25706E3 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) by imf01.hostedemail.com (Postfix) with ESMTP id 0EA0F40013 for ; Thu, 14 Mar 2024 19:29:07 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fbZs474P; spf=pass (imf01.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710444548; 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=L5mYCuAgW9WLpcKyE4vY0uyy9Nn7D3uKkSmdVzmlRCI=; b=K0kyOtdZ0qK+2xShBUVJdnyJrXqtzQwIdfy2MNqugf1WhV4TacxtZ0DFHYSe8PpbNKekU+ EkDM208vpqYzOWKAEwT1f7Laza1P6ImWo1w3NlMvnd/3CagJvTxuKemm0DAtTBamYvr0t7 vmakGIs4ts5q20l8r7Nt7TyeQLTLjrc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fbZs474P; spf=pass (imf01.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710444548; a=rsa-sha256; cv=none; b=IIjgxyAiYus9twYOfUQfjL1icG0dnAhm9okopBfaqvbSOWawOUCogDCIyVacOsyzDIcZ1Q sJs6chFfW81udlKTXIKKj8BVfIIsPKxCehIHHOFQ6sHe1FhptxsfsxnuMhmKMQt1vcAzUD Uhe7fBk+MHUHL0gD8QH/hRfHDbyiJxg= Date: Thu, 14 Mar 2024 15:28:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1710444545; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=L5mYCuAgW9WLpcKyE4vY0uyy9Nn7D3uKkSmdVzmlRCI=; b=fbZs474PeXyIJsZK5v+BHUEn0x3cCbqr1L1c7WYw9Hu+WKErM/0yY5IIXojQMN2YnQp1Zd 6H1hkW7SqyHqpXtHe+KmDPq11pUwICXj5kIueCxQFkY/JD5ZYSGZQBxvpGiVhAf9SKK7lk hlEXwUWHcyBFdVZOz9JTxpG6u8Btf6w= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Pasha Tatashin Cc: "H. Peter Anvin" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, x86@kernel.org, bp@alien8.de, brauner@kernel.org, bristot@redhat.com, bsegall@google.com, dave.hansen@linux.intel.com, dianders@chromium.org, dietmar.eggemann@arm.com, eric.devolder@oracle.com, hca@linux.ibm.com, hch@infradead.org, jacob.jun.pan@linux.intel.com, jgg@ziepe.ca, jpoimboe@kernel.org, jroedel@suse.de, juri.lelli@redhat.com, kinseyho@google.com, kirill.shutemov@linux.intel.com, lstoakes@gmail.com, luto@kernel.org, mgorman@suse.de, mic@digikod.net, michael.christie@oracle.com, mingo@redhat.com, mjguzik@gmail.com, mst@redhat.com, npiggin@gmail.com, peterz@infradead.org, pmladek@suse.com, rick.p.edgecombe@intel.com, rostedt@goodmis.org, surenb@google.com, tglx@linutronix.de, urezki@gmail.com, vincent.guittot@linaro.org, vschneid@redhat.com Subject: Re: [RFC 00/14] Dynamic Kernel Stacks Message-ID: References: <20240311164638.2015063-1-pasha.tatashin@soleen.com> <2cb8f02d-f21e-45d2-afe2-d1c6225240f3@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 0EA0F40013 X-Rspam-User: X-Stat-Signature: ym84hfe3jr9799sf6qooeuf7bsiwhf3t X-Rspamd-Server: rspam01 X-HE-Tag: 1710444547-388443 X-HE-Meta: U2FsdGVkX1/Nm4FXpdoV/1UD4xurXRteHhqs7Y07HRIcuzjP0OCguoijtNedViUyrpq7+7VBeQEvyj/0d/uJKcFgiowHALA5fC0jg9HOavJrUiIjG5R1sVNmdI+vHF8fDYEQwroJugCGxH60jHx/gRaHMV7N5u7+dZWxoHq1XKAX1G9pTWysawAOTr97SiRHu0l2nXTXAo4v5lnVvu+d7w/rsvAcqI5ScxuhAw7EjJ88ysknanmWiW93t9NLu/ndiYlC1POEpMfs5OaqJVch3UaPfdm69pwPE7UNTX0l/BduMA5PL03POnCdgrWmJo8/otyp8UWeEbew3u9tK5sjzryaxWYDz/8vqIErm8A6HVQMn6MIdSZVRUTGIDsCmtH0sj92aEoEx+PJ7JHuFymi3yapc1mVkubMj6teoWjoKpjOcOs/RbCnwYcCv4aTIwcJV0KSE2T++ffM8YnUBBzZJ6pZPoq92ykHQMLhBSfAAi+TzN6srCfy1Ot+op8QkEtcg9GTnRU6VC/+7ZAPPMpqQYlwRRiX5eobMXlVPFmPrDGUvRGjI+/yqcRpuLMMm9wn4iB3+75TA1SmoI+/0lwucTz0k7hNFVy59WTqCwzpD3ArLSYj8O+MYVVYQvb+yenhRqc5G6HulEYFuK206mCh2b9pTZiFWsmuXV0hzJN8isH4RZUkYFjUpwqZZfFOxIN+FwN5HXCgRwZhtLXVwmZLR/CVqjcWy7Ybjy5V5d+6VECons61+zyhj/vhkiaLx6UhTB+tPHUZtM5GFe9sYYtWU6PN7AKM4PlF5E0v62sTX7w= 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, Mar 14, 2024 at 03:23:08PM -0400, Pasha Tatashin wrote: > > > > > > My point is that what matters is total memory use, not just memory used in > > > the kernel. Amdahl's law. > > > > If userspace is running a few processes with many threads and the > > userspace stacks are small, kernel stacks could end up dominating. > > > > I'd like to see some numbers though. > > The unused kernel stack pages occupy petabytes of memory across the fleet [1]. Raw number doesn't mean much here (I know how many machines Google has, of course it's going to be petabytes ;), percentage of system memory would be better. What I'd _really_ like to see is raw output from memory allocation profiling, so we can see how much memory is going to kernel stacks vs. other kernel allocations. Number of kernel threads vs. number of user threads would also be good to know - I've been seeing ps output lately where we've got a lot more workqueue workers than we should, perhaps that's something that could be addressed.