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 F0D1AC54E5D for ; Tue, 12 Mar 2024 19:46:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8212E8E0012; Tue, 12 Mar 2024 15:46:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D16D8E0011; Tue, 12 Mar 2024 15:46:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64ABD8E0012; Tue, 12 Mar 2024 15:46:26 -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 4EBC28E0011 for ; Tue, 12 Mar 2024 15:46:26 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 147171606A9 for ; Tue, 12 Mar 2024 19:46:26 +0000 (UTC) X-FDA: 81889418772.03.70C74E6 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by imf01.hostedemail.com (Postfix) with ESMTP id 5A5C240006 for ; Tue, 12 Mar 2024 19:46:24 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=GYMSDPpL; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.167.171 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=1710272784; 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=+k5a1edRWn/GNqW+k0d2uxrg3xuipstfEZ2u0wtLdYU=; b=gBS8gVOlL0UwYnMjKiX5Hv1xa7xLfYrjkVkg9ZcDCgKjLo3mpHtbhQ9qddWl82qDEulBra eT5+oljDSLl2OXYy2o+FivElj1Ir855i6RBllzDmfK28tSs6KuhVBmRREBKwdLaAwdwLyh DGU+YhMSF7vGCIc/uTnp8bw9CR57NuU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=GYMSDPpL; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710272784; a=rsa-sha256; cv=none; b=L692xcCEPhX4dI2i5ioQ6+coSlM5CQGhcUjIpNiFiCUrRVHOw1NtAqM6EYQbObqZhEdDxz 7wy5H9+BWfxEL/xfCjow0H99AhpFIpsHVaWrz9jcQFEvnsdkOWGDPSkzXDJ1OD2SZ5Fv9n KJetlnv0uJTBCwnwBNOCRWGaNPq1pv8= Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-3c19e18470aso3882409b6e.1 for ; Tue, 12 Mar 2024 12:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1710272783; x=1710877583; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+k5a1edRWn/GNqW+k0d2uxrg3xuipstfEZ2u0wtLdYU=; b=GYMSDPpLdXtZHJ1/fLQKveoAeX1yT62u/JMUt4yFDjWERBF6YOJDZAgWQAeJ41P5mj j3ig/0E5oMck+oDzOfcwE9tXMdTq6rOMAWZD3FK02YHbJNSnAvhNdtkQ1a311nzzZkrk 0XikSGWithRdAPRaj0ozi2SbLuk6i8EowssNmiyHMihvPVTcDFBD2DugsfisxSxjfqeE TD87sGTTcETVYYRK8ITFF9s2aPK0aT60E3nBQce4otv0OD7EDXTjmamN2rYcS/ljdeSH j2rnLFbux5ysMFXRxrzT09o26k86/JlkSiZR0lXhqkpU/ABb6HC8b015nmLv/WPYyGCd 38hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710272783; x=1710877583; h=content-transfer-encoding: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=+k5a1edRWn/GNqW+k0d2uxrg3xuipstfEZ2u0wtLdYU=; b=ppk2XuEzCHisbls3dut9B+N8ACYbOKAEUWaxca24qLPVg3C9MQ/aGAHSHvQyuGugjQ ABl0iW+3hYlAgX8707YzYNGOKFf8MaqlQTpjri4QgHZJTFP+M8sIqKraTF9gbFaySPl4 HzKcITl+NYvY46NoXKU8nY0ix6xN0WenH2tlEqJyl/MPLbhTrSxprr4giP1TYcl/PaS0 Fwi+H20nIEG67IiE43RTahxUAvqWXd7ia4JsT65nEKjGCihliadduFcLul7mBrZWGlcO 2+yVj+8kMjWdlP7TbAgiEG7SmmRutchGsQAwbk7q314PRbrNW6kHNAXeGl2JglpRPOWC VtFw== X-Forwarded-Encrypted: i=1; AJvYcCWcklAOUwA7nPbH5d7V/wg6qAxZrZ9Ds+MbWpDN/09VJC/OyEf0cPTiwepr0GA3a4LrZ5uOR+EYVGJ5M0vmq6HtmOQ= X-Gm-Message-State: AOJu0YwlxJyhjyRW3L2fo57DdSSOqL9S5PZ7PVosE2wdnCWUL3cQOzk6 5b7ZWkjo+XT7ieqG2ayDL0WWszQHluMEzezwoA7fK9xW/vyQCxMudNYa94M7eOjvEmP5BZbwe7v 7ERDzzdzFUhz0MGXhU60H5l05V+/g5Rx2H4IvXg== X-Google-Smtp-Source: AGHT+IFCSecG9JVro32J9SgF6VVa2fZX7giCOM+EunUYFBUZXmDzBkZ/0+GBTOC0v9b6/Zvw5GomwU16QkYU+z1k1Eg= X-Received: by 2002:a05:6808:1528:b0:3c2:1792:105b with SMTP id u40-20020a056808152800b003c21792105bmr13478223oiw.43.1710272782623; Tue, 12 Mar 2024 12:46:22 -0700 (PDT) MIME-Version: 1.0 References: <20240311164638.2015063-1-pasha.tatashin@soleen.com> <2cb8f02d-f21e-45d2-afe2-d1c6225240f3@zytor.com> In-Reply-To: <2cb8f02d-f21e-45d2-afe2-d1c6225240f3@zytor.com> From: Pasha Tatashin Date: Tue, 12 Mar 2024 15:45:44 -0400 Message-ID: Subject: Re: [RFC 00/14] Dynamic Kernel Stacks To: "H. Peter Anvin" 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: q8z1gyfnojgc77hu6tncjbq1gpmcq4az X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5A5C240006 X-HE-Tag: 1710272784-108548 X-HE-Meta: U2FsdGVkX1/JUUb+CpLG/KhVkvvVAWxhKsq8EIdgmkAtdBSu9JfLgpGtUq9cQUuBvvMyCXYFwKl+O3h9Oww7yYbmJgJY8sO0gm7SrBD7tDkvgC05JQbKAAZi+c5Mz3z8JdQJfcLd3cIldFDnaZowE9/Rl/fVbiFIo3t2KsuCpO2j1Pp9bsQZlfKWv6vnqtmhJoTlqRlK3BSEoU04jhBQxwmn9zA/J3kAxPHDJnDYWqox6AV6wE/+VX7UIGzIJKmX9u+Y40wJih163Er82Qc96kxVQb61l23BCbejYeANxUP7ofyRn4XtemXtuzDFWWku8+iHDZ6yZhPwV9TMcqGAE2emLDOCKmidLhmCFgdkttOq4xTGU9fJSj6r0yhmHBXGHl3IU44ebp/K/Vhl/zX7P2wCV/kljx+OluRebEYMVo042E4jOKyUIUlm+X8R6eSZqBHdECV/82ArxqvU9m/Z2gri9pMy1ycaOr4b9lo1Lv8bERcvq9a3J8i2voSd9iS6+VTdVAxFIdlJ1SOOkH0ff1/RpuCte+6/AOLnNb+I11fzVGpehZ1ZqRIdrEmtwOEPyOMf3DRUNRDqoNhPrf3n22ic3UGuL1NH9EjTjN983ESrlwvP3xazT2T1acQsGURkxFLHoEIu8ex4myQy618yy3C6baO6Kj4bhalXajGwN/AuTmzUVDeJiI7JpicMU22ath72w6xWLlmJ7bozcLBDaFYMeU1pQ2u3JxfGXN6JkNKaVOZ068QkJwDUZnh/lX16Ni0sx13tf3uD2MK6fvWuMY6ouE66QC/7I3uhSWY8QC7jMbuXkvh+56xAn2gMQyykmFVLcVEiJqJUzIs8xvZy0MQWlDBvBea7ldR+GzDdbn6DL9ryZ0n2n3Gy5CSJwEaGRlzwKufhPem4g+e1aAm7emUGC88G5Yz9IaaUidDzuPIMDsbVM48J2vmk19vGel9KsbYrTrhH1gW3AYbxXk/ OU6/ufd6 OnI8ITAvHPADIaYEWEq5DvDD3F/zBFWHjhEhaxVt4QSZxZeeLPZ1UsI0/7w== 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 Tue, Mar 12, 2024 at 1:19=E2=80=AFPM H. Peter Anvin wrot= e: > > > > On 3/11/24 09:46, Pasha Tatashin wrote: > > This is follow-up to the LSF/MM proposal [1]. Please provide your > > thoughts and comments about dynamic kernel stacks feature. This is a WI= P > > has not been tested beside booting on some machines, and running LKDTM > > thread exhaust tests. The series also lacks selftests, and > > documentations. > > > > This feature allows to grow kernel stack dynamically, from 4KiB and up > > to the THREAD_SIZE. The intend is to save memory on fleet machines. Fro= m > > the initial experiments it shows to save on average 70-75% of the kerne= l > > stack memory. > > > > The average depth of a kernel thread depends on the workload, profiling= , > > virtualization, compiler optimizations, and driver implementations. > > However, the table below shows the amount of kernel stack memory before > > vs. after on idling freshly booted machines: > > > > CPU #Cores #Stacks BASE(kb) Dynamic(kb) Saving > > AMD Genoa 384 5786 92576 23388 74.74% > > Intel Skylake 112 3182 50912 12860 74.74% > > AMD Rome 128 3401 54416 14784 72.83% > > AMD Rome 256 4908 78528 20876 73.42% > > Intel Haswell 72 2644 42304 10624 74.89% > > > > Some workloads with that have millions of threads would can benefit > > significantly from this feature. > > > > 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. > Second, non-dynamic kernel memory is one of the core design decisions in > Linux from early on. This means there are lot of deeply embedded > assumptions which would have to be untangled. > > Linus would, of course, be the real authority on this, but if someone > would ask me what the fundamental design philosophies of the Linux > kernel are -- the design decisions which make Linux Linux, if you will > -- I would say: > > 1. Non-dynamic kernel memory > 2. Permanent mapping of physical memory The one and two are correlated. Given that all the memory is directly mapped, the kernel core cannot be relocatable, swappable, faultable etc. > 3. Kernel API modeled closely after the POSIX API > (no complicated user space layers) > 4. Fast system call entry/exit (a necessity for a > kernel API based on simple system calls) > 5. Monolithic (but modular) kernel environment > (not cross-privilege, coroutine or message passing) > > Third, *IF* this is something that should be done (and I personally > strongly suspect it should not), at least on x86-64 it probably should > be for FRED hardware only. With FRED, it is possible to set the #PF > event stack level to 1, which will cause an automatic stack switch for > #PF in kernel space (only). However, even in kernel space, #PF can sleep > if it references a user space page, in which case it would have to be > demoted back onto the ring 0 stack (there are multiple ways of doing > that, but it does entail an overhead.) My understanding is that with the proposed approach only double faults are prohibited to be used. Pre-map/check-access could still work, even though it would add some cost to the context switching. Thank you, Pasha