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 25AC9C54E5D for ; Tue, 12 Mar 2024 21:37:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B4B48E001C; Tue, 12 Mar 2024 17:37:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 764B38E0011; Tue, 12 Mar 2024 17:37:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62D3F8E001C; Tue, 12 Mar 2024 17:37:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 50E268E0011 for ; Tue, 12 Mar 2024 17:37:27 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F088E40150 for ; Tue, 12 Mar 2024 21:37:26 +0000 (UTC) X-FDA: 81889698492.21.9C3A31A Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf14.hostedemail.com (Postfix) with ESMTP id F157E100019 for ; Tue, 12 Mar 2024 21:37:23 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=zytor.com header.s=2024021201 header.b=SzI4tb33; spf=pass (imf14.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710279444; 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=RJ6XaDgEz2DLax9EMzFHq+cdHoLC0FUJtliEoq1/zbc=; b=BpkWmDFfJDsq5SVHrKR3RZoJNAk6Urza8EY3Z/heNq7FedRnfc1xfMdnIf6WvZHM658DLy Gv5t6g3FfwojOw3PumrXpsk5U3HPSi3qIQiy4b7tnceX+ED7YDRhA5xmIw1o/CXmZJdyGF 0wHzovBIGDYbd7V680NMvI362dF2KAM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=zytor.com header.s=2024021201 header.b=SzI4tb33; spf=pass (imf14.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710279444; a=rsa-sha256; cv=none; b=t4StpT6JDO331EtkHbbel+JnHo36HotKiAacuMshbBxCxIyxSMR66Ilyh8WonL4VWJRlz6 awcwxR4bkLsUug2cRN/cJEKCbDKG4x3MVSt5Z6ofU/DhA3BRgPeeIkZyA5xgTK+04xTYb/ cKstCJyhEn5DtRPhLYXn7lwNp+APszY= Received: from [IPV6:2601:646:8002:4640:7285:c2ff:fefb:fd4] ([IPv6:2601:646:8002:4640:7285:c2ff:fefb:fd4]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42CLaWIK1697040 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 12 Mar 2024 14:36:33 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42CLaWIK1697040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024021201; t=1710279397; bh=RJ6XaDgEz2DLax9EMzFHq+cdHoLC0FUJtliEoq1/zbc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=SzI4tb33XKwcapGVtECc4PFS1Mg6xwLKcQe85zGUfzhNscSAFhHM+mpedeoD9/Mnw ttyeN60qWpkCDe+8ZbUGpbEU7MQ2IYgDiIydtsWVa/QNBe0FoAQwD8Q9txbUIJErF3 nMyZqkcLHfAuSQspvc5Z0SvNY4YuQcHHtUgkk0oTvKfXWhGto36ljWImPF5N2QpuHZ SCBOlR9Kyuv25sGz6LBdozcKXfm5Sk4ZgEeuPtbWJNKL3w74Ul3AUOf8aNP0XXEMAR PpGrBpPrdAKQ9ipTDJswtiZoiCpvkR4G5avDtj1PdYJm6vdbSOMUWOKLux28kGtio7 vOneQoNEQEeAg== Message-ID: Date: Tue, 12 Mar 2024 14:36:27 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 00/14] Dynamic Kernel Stacks Content-Language: en-US To: Pasha Tatashin Cc: 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, kent.overstreet@linux.dev, 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 References: <20240311164638.2015063-1-pasha.tatashin@soleen.com> <2cb8f02d-f21e-45d2-afe2-d1c6225240f3@zytor.com> From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: F157E100019 X-Rspam-User: X-Stat-Signature: 1hz944yo5qd8ozrgwx9omr5ens9t79re X-Rspamd-Server: rspam01 X-HE-Tag: 1710279443-944397 X-HE-Meta: U2FsdGVkX19FO6snd2o0kKBvBf/WMGGPBRS9jYaLUMU463aagrTrWJOI5TSsT9wpH8Gmik6trjMgq1FdEmpherXMF54BrRrqCy5tpp1ktjMSTwXQYn/P8AYP3fk3ibIxTlBs0eCG8wlE/kPUQGRfmFl+WgizTsk8JZtytNGiGTBt75y97Y6u9qdPy8tAomYes0jVfezBYG1vfSoJTohKm5raKxYaFclCkzeGd8TCBY+i2wQpGZUgaP2B2LqW9kmgH9oVyjRtu8R9PHRrqt7VZ20xABXCX7ysFJ4D1K+1N4cSWblpBHUCLw+GpZ6y80141STYrMyMOswQGWUNopZd+1MFnauI7UBYZgUxfslcDrmBHypJjxoCWCN6q1U7Y7FwoM7YlsX6w0C07QB9rCowCy1VrSPTeUcfqxOtC3OYopyPY+noAuA/xbVlqNAJqMlix9j04Op9L9GjRrskgv13plx8OCAAEzza6CPXPoyq/Oe0ZWnQpzfJh+yLL+Q46UToaqpEVmj7eJbsizVDvgX1elMN1ifNtn80fw0H7t/pdYSIu12ghYzEtPBmq3WyIwkQqWVWcwUEJawVl1Ne5YMFYuR33Rv6bnp3airoL+2V3rKaLctndIrwzrqkTEJmJg2/FGDLUw8qRDVYpK/urv3xcdVG7JtDGZNv8EeRGK3aAP4hq9lKDxyTIa/2HBDvo4fM7itiLeZzyxHpFlSlrcLu/9dFJSFnKEdHozIqdS5rdkABP2QDiasBjkDFrcw9aPEznssmJZKxq5sIamVW9V5xdbiQV6dpygW479l5IT/D96oxkJ4pIbwzJJlnSRQwwXBXQobpW2ETrqN26iV87kjm3hKM+T4LBdvv4OohrIoi3vOA+qD/75u2Qp3iGpvmqoeRw6ALtmsJJpf/5VsBZbbtKkmAmEkzx57vtX49yyNHtp+PVHs5OtytC/g4xssWvN70SVqoHQnXqbuFgcTt5SN 9cTczxSQ 9L+v0WdluDFm9fE/Y7qqpchK5rWe8Rb1/9EH95MNc5ApFVQsRHqr/OsuPra1ASZ5aurFjkPUZ7FHFb09jDzrzxPnpAU75Whkyfeq75qpOtt1e6ERMl11XpiEQAe8mfd9BkpFGVdBRjcm8gur4bNktvata08GAntGo9tFEeOkHw1GRVd85wcgexdeiWdbBCrZ3hrWqZ6HtOsGCdNOT2RuMGWN5vekRtrn9sAUWo9p5MBtFDmzS2Mw02xW4rQ== 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 3/12/24 12:45, Pasha Tatashin wrote: >> >> Ok, first of all, talking about "kernel memory" here is misleading. > > Hi Peter, > > I re-read my cover letter, and I do not see where "kernel memory" is > mentioned. We are talking about kernel stacks overhead that is > proportional to the user workload, as every active thread has an > associated kernel stack. The idea is to save memory by not > pre-allocating all pages of kernel-stacks, but instead use it as a > safeguard when a stack actually becomes deep. Come-up with a solution > that can handle rare deeper stacks only when needed. This could be > done through faulting on the supported hardware (as proposed in this > series), or via pre-map on every schedule event, and checking the > access when thread goes off cpu (as proposed by Andy Lutomirski to > avoid double faults on x86) . > > In other words, this feature is only about one very specific type of > kernel memory that is not even directly mapped (the feature required > vmapped stacks). > >> Unless your threads are spending nearly all their time sleeping, the >> threads will occupy stack and TLS memory in user space as well. > > Can you please elaborate, what data is contained in the kernel stack > when thread is in user space? My series requires thread_info not to be > in the stack by depending on THREAD_INFO_IN_TASK. > My point is that what matters is total memory use, not just memory used in the kernel. Amdahl's law. -hpa