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 CAB62C54E60 for ; Sun, 17 Mar 2024 00:41:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFD476B0082; Sat, 16 Mar 2024 20:41:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BAD1C6B0083; Sat, 16 Mar 2024 20:41:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A74986B0085; Sat, 16 Mar 2024 20:41:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 961F06B0082 for ; Sat, 16 Mar 2024 20:41:51 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3936AC04A3 for ; Sun, 17 Mar 2024 00:41:51 +0000 (UTC) X-FDA: 81904678422.16.01ED559 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id 07090160009 for ; Sun, 17 Mar 2024 00:41:46 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=r9SxkOpx; dmarc=none; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710636107; 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=861eAApZXU3vRWwZN8NtN/fYtVMSBl0R3WWZ/C06Z0Q=; b=zeXjEI9KDJ3nTJ2PxWZXKHjtg9e+/e9dKxwYSyvhZ/f386/cBVKGKNBeBvXWo/yVSG49nD MYx3hGYtr7ZAgJsPDjIn0Emj7sk31KH9fOCnbahFtJZJxtywo38l5OaX7J5XPpNWrbhrVb +b8x9vRHypjRJk7sdEbcHut6G1JtGHo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=r9SxkOpx; dmarc=none; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710636107; a=rsa-sha256; cv=none; b=AcepYOEzrJ2oQqCCj0pLnxpGgx0o+1rONxcxIRUYtYtpF7Gw4JDzRKIHOyS+e1/oISnQP1 dOTRdBcDkQLjcxYc1DemNlYcSlhiqSa1izlFTZPmhyWFeWG2dGe3MR5wnnBQ8hPaxZjEJh URK+xI5d3ke4dYBgzJtC1ZRjdAplfLU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=861eAApZXU3vRWwZN8NtN/fYtVMSBl0R3WWZ/C06Z0Q=; b=r9SxkOpx8uSxPEXiP+T4k4YbNJ S3eEb2b5Vpi8f6A8oMByvAXoYB3SXV6n+MW35TNtZ7/qEhUzgzNoSUcmcbWPLYOFco0/m3wpt0CQj iCFUMsRj8nv73rZCeRdj72QGjSpko+mUlLVALjH7fNEoDhCu9RvOf6LarDDMbRN9vigskiOWlsC5j ebFn0EAeFzGeOflSwEf+ArT0jpvN76o2U8aCtX1/usKVBkF1kjzsQMrHT37Nc1Oo3JYnbL8Np5Pfu MEeOQbTPrhoWVACzqbRyPrXaJxxaWBzc/xBakX1Xk5LKF2GA9+wYvYv7Y3Ou/I4gnkz+WK8Rv6wwK ZsMXA7XA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rleaj-0000000Dbuk-2kaT; Sun, 17 Mar 2024 00:41:33 +0000 Date: Sun, 17 Mar 2024 00:41:33 +0000 From: Matthew Wilcox To: Pasha Tatashin Cc: "H. Peter Anvin" , Kent Overstreet , 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> <2qp4uegb4kqkryihqyo6v3fzoc2nysuhltc535kxnh6ozpo5ni@isilzw7nth42> <39F17EC4-7844-4111-BF7D-FFC97B05D9FA@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 07090160009 X-Stat-Signature: xmg8u1qau3c9k9yf8cozhswkxqdk99t7 X-Rspam-User: X-HE-Tag: 1710636106-914243 X-HE-Meta: U2FsdGVkX18yDpI6VONNwJiL4NITnva9KF/gLQC1wofu5KFWjQt6Lk+bHEl0H5nJRil0cFtYtsz3NGRjp6VbmU2Py8HtpTjyY4T1Fs6H9Ipaxvm5TtNDRhG7UrN4oYdlfOvGlDve55ekNZ7NOq7qvleHgzRbsDY6r+JfkX56HqgmZonFFxnmQ4g9gMBCZ1UVE/bwhEbdbU8LpyVs5pEfOnE9Jff2jl2TpdQkmmjqcca6SsFnHhOHxbYAwcS6UrJmzsJyZH1r8bT7HeHmkh0HFCeysQishI+nBTmC6JsVmiMTdsXU4RrIQXK87z7cgzkLg6f5QYge64ZWnAPEtIZLW7WoC2znH9RpO0B2zLOujg9ty9mHvyTx602BZaMK27OYI3rpgEkhvs3OiM2bBCqxHahI6M2VMCn8tohU/dtLAzrDnPwMDV1ZwSTp2taAyYc8X2OS/aW0kzfVr1td0U6IM2AL3o3/9WSy56vq+VcZhpJvJ6VluvQMafVC7QFldBmfbidKYjJm6XNsrLS8ESp/E3sYSHskxEKS/JQ9Cvdnjv+4xqcqGiJwcEB8uIOiMIDMOnx05W4ZZphtYKorbAzbLTN3lyH4mTucXXNSZwe8vYBLZPeXoEu/NdE3GJ4/EAkMLop6iNUQi2p3UJW0dTzC+pfmkqeNUGTBORan0fsMuXNzZcvgZi7BgF43DbKd1jl7t1pYTB+V2xUqC2rhvr7rn7alNmr1D06kzEVzLV48w3uDwbXi4PT5Cesjhh2i/M6BiweBZGZ817bVNdQQMYBBrnb0/zhZebaAFxJ1yBd4FU19qppxfrNkQWfeK8FPId/tDVKXZL3DGUoHtiWnTUQm9tFswtqyQ4vWI+ZiQiighiVBXSs0I3JhI8243NCyU+kRSdhRDoCJg0IMwlwiqbIqI7HyCpqqafHStNADd1KAXTGpLK7vof/+rdBe1w5ScG6LgW4RRUZyIJuYoJIaJaE o/imcCqb 765j8um3gx21c0BRB3RnrP+BoGeeoqoXF+HzaUKY8dL5DYyIYD1uZ/5W72NagwnWTpvPgO7th1S0EPcQnQrWWdcb7FNX7ODMkPSnaLJIJ40j7/Ym4P2BRZbAhR9JYJ2bNmhr9R9Qz5UXJpYI= 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 Sat, Mar 16, 2024 at 03:17:57PM -0400, Pasha Tatashin wrote: > Expanding on Mathew's idea of an interface for dynamic kernel stack > sizes, here's what I'm thinking: > > - Kernel Threads: Create all kernel threads with a fully populated > THREAD_SIZE stack. (i.e. 16K) > - User Threads: Create all user threads with THREAD_SIZE kernel stack > but only the top page mapped. (i.e. 4K) > - In enter_from_user_mode(): Expand the thread stack to 16K by mapping > three additional pages from the per-CPU stack cache. This function is > called early in kernel entry points. > - exit_to_user_mode(): Unmap the extra three pages and return them to > the per-CPU cache. This function is called late in the kernel exit > path. > > Both of the above hooks are called with IRQ disabled on all kernel > entries whether through interrupts and syscalls, and they are called > early/late enough that 4K is enough to handle the rest of entry/exit. At what point do we replenish the per-CPU stash of pages? If we're 12kB deep in the stack and call mutex_lock(), we can be scheduled out, and then the new thread can make a syscall. Do we just assume that get_free_page() can sleep at kernel entry (seems reasonable)? I don't think this is an infeasible problem, I'd just like it to be described.