From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B7AC3955CF for ; Tue, 23 Jun 2026 21:58:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782251901; cv=none; b=P0CQgMWrKLiejuHiI2DypE6cdcoYDoXapLU0BmxLPn5N9Pv1Lj5s8SMOCuhGoLuQ4yApF2H6gcbCK5Drdevft3zKOGJ1ZZGRl2hcqD9KNZkXuojJfAYRX4SrXgCf3IkVIEiJ9ehZ5ZWcDHn63xhlgRElU00jwzVPayrxeucGcOQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782251901; c=relaxed/simple; bh=OkGyeT5GHMe0qORh+E/csoVVF9qeirfH62Nt3/uyAgM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=U18Ce6zDGg1N+ghKpgr9dZitEWQoM8e6d0rLb+FI3QT+VK0gSbzYdA4f26G6F+QFKnsN/MlbXbtsQkb6dhoGvjWD0FBLJ8hwxQZbU/cnV4EeG037J5XbdbS4J9S28wrZHcxeYFwfz4m3Sc6Cd2EERRXzs7cxKvgwyhNLa9Qg/VA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QgXbJUld; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QgXbJUld" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37A201F000E9; Tue, 23 Jun 2026 21:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782251899; bh=1HgdF15n4Z+of2TIKTLD8EBd2z4e9EArUoGmg/pRlaE=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=QgXbJUldX745itn18F6Yyf7zaz8eGN7HM6q6xRYrSDzS0ZZqQ2cazPACHRQkuVvpn fY0CXR18Eh8V96uEgstEnCzpSREGT8jtturxySdile6FshiamY/B2k6dhqkNMAqzbo u/kgLP5L+K8rgp8mq5DfNTP/+2HQhWabTT3o2lugATJ6OdQYQFCt9r2flUxQ8b6SHK AQhYpsn/qdekcLbR6/WnGEK0agFs5UPFDJBEdh6KEOOsYlCF52Vqbr8dhh1N5eutuu WfFrbhB/yCGIRpOoBxmbAkOHvMDF4Ti9bxzW5t0NPFp7bwBNI+3+7MTfZaqw5pR7kh BSoVf6GUXA9yg== From: Thomas Gleixner To: Zach O'Keefe Cc: Dave Hansen , "H. Peter Anvin" , David Stevens , Pasha Tatashin , Linus Walleij , Will Deacon , Quentin Perret , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Andy Lutomirski , Xin Li , Peter Zijlstra , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Uladzislau Rezki , Kees Cook , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 00/13] Dynamic Kernel Stacks In-Reply-To: References: <20260424191456.2679717-1-stevensd@google.com> <6369e5ce-74e3-4c68-8053-d7d7d21b6955@zytor.com> <87pl1md7h0.ffs@fw13> <87qzm2b39k.ffs@fw13> <87mrwon5uw.ffs@fw13> Date: Tue, 23 Jun 2026 23:58:17 +0200 Message-ID: <87cxxgly12.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 22 2026 at 16:00, Zach O'Keefe wrote: > On Sat, Jun 20, 2026 at 4:34=E2=80=AFPM Thomas Gleixner = wrote: >> That said you really have to describe the scenarios where there is a >> benefit and I do not buy this "fleet level" argument at all because >> there is no single fleet which has a uniform workload distribution. > > These are good thoughts, thank you. Perhaps I've been too biased by > our particular environment=E2=80=94apologies for that. > > We (mostly) punt this problem to cluster-level scheduling, which > ironically exploits this non-uniformity of workload dynamics to > appropriately bin-pack machines and materialize these small savings. That makes sense. > In the general case, I guess a lot hinges on that overhead cost -- in > the best (memory-constrained) case. Right, we need to look at the wide range of use cases and avoid to create niche solutions which impose maintenance costs for everyone. >> Aside of that. If your argument holds that there are only a few >> scenarios which require a deep stack, then we are better off to identify >> them and fix them up rather than trying to hack around the occacional >> insanity of deep stack usage by adding complexity for complexity sake. >> >> As you say that you have numbers of your fleet which confirm that the >> vast majority of the stack depth is below 4k, you can surely figure out >> the information which call chains are actually exceeding the limit. >> >> I prefer to fix such shitty code and downgrade the stacksize in general >> instead of papering over the underlying issues which probably have been >> ignored for years if not decades. >> >> Have you ever thought about that instead of adding complexity with a >> dubious value? > > Yeah, and that is certainly an alternative path we can explore. I was > _hoping_ to be able to maximize the savings here, via the >90% case > where 4KiB is sufficient. If we instead play whack-a-mole with the > handful of cases requiring > 8KiB, the best case is we can move back > to 8KiB stacks. Ironically, I was thinking going this route would be > _more_ of a maintenance burden vs having a generalized solution ;) It's actually not. The point is that we lazily punted to 16K stacks more than 10 years ago. If you read the changelog carefully there is an implicit request to watch out for stack usage and to fix the offenders. That's obviously not worth the electrons it wasted to commit it. Software people are really good in not ignoring such things as long as they do not explode in their face. :) So as you already confirmed that the number of offenders is really low, it'd be definitely a worthwhile effort to fix that for everyone and also make the compiler people to get their act together :) Once we got there the complexity of this becomes smaller and we might have a common goal to get the other 90% solved. Thanks, tglx