From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 791613403ED for ; Tue, 23 Jun 2026 09:10:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782205824; cv=none; b=RQ4z5pEP02qRyYVIQj2CNT2paJxmh2+tMSMl0hRrFoHGP0bqPYtzrAlKdAXG0lagnNyJduisKIJIfmjx7V+z7hoA1LE9ubwarqZDuPhpIrvoctsq5hYT0MZA9ncQeceaUrJAsUJ3bXuy4xfTSp9Z346QRX2Z+pV6kCbCkPFlP/E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782205824; c=relaxed/simple; bh=irSdrs6aipwC8zdlD6lv4tXa6fv7NBg6MFcJzvA5Riw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HwEVum5Cex6YdGM2YTNGExkR2K2Uz0UN/MoWpPh9d+WKmLn1rr2Tyf4veuNwVrtO1V9bxXXiXk9eKoJuc7n354A+XNerQyajdEMDi+Y9cX/WVyCKKRPw5tPnEL/v52L0NbZrDgup0oRTERC0ymGZQhXLs5W3dsXlAj1GqrZp1Xk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=o8wC0CsL; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="o8wC0CsL" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-490cf322ed0so42059465e9.1 for ; Tue, 23 Jun 2026 02:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782205822; x=1782810622; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=RmkBF/F+ufBgZMZn6F7DXZ929zTCk8KNdKVzQpVyQ8s=; b=o8wC0CsLyYMtbZp2bwrXeCe3Sg63DKSpQAKztGEFU42yjumuyzNjfNKrjZ4UHYTUcu bUwN7CNHoIj80iUbFhSsaFvpk7mjQWPlumemED47mU8L5v3oz1FKzzuRYHQT3oU5A6EV qp4ETS75JKCFkIaYhXmsx1MJVpJ3N7sTNYyOzH+PKMDDTaJOSLRwT7SL175YKBgU3Swt 01CfwhdsTQs3lo+aBE+PNVVyLEj4Iwim4ZFIUVw7baNmeTRxQo0eUXit673mcxYe85O+ u2l4OFgYr+S8tyup4CpIzqtRjpOYwDtnKOWHhFNhppulsI3iioDrKT4NC0f/d2LfVgxI e5cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782205822; x=1782810622; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RmkBF/F+ufBgZMZn6F7DXZ929zTCk8KNdKVzQpVyQ8s=; b=RXGgGeNCBmC4YHUrHMXzTFpfgfyV7mhMa5YosyEt0q3D1Up2uKerKbsbmIwNE5LHfx oPmTy3w1sSocRKxwJWWwRIX5RTUVF4R5K45Jp76Vx/TXd8RWOuoTPcnGqa+Nuskk3jQg bTD8eurXb/19fDiXHaTlhdsznMk7i5ny+yw8XMdNgsbuwmnKil219gcwjNjX6oDPS9uS k9SHZeEN6zB39FCSergMiXY5816qCc4ZAAWsmoQkkQ/00q4SceoljP/W540bl2SlPhCq JmfomlKWSsgc7vA/id0yDH7v129zJjj1wKgtLGJ0KpX58Me0chaci8cXqB2vv7jAYxBt DWKA== X-Forwarded-Encrypted: i=1; AFNElJ+bi0yOR1vM0D4HUQS6MLDjL4fvc1Adkx0qexGDKEcTw0uGCPmoYNqIV2JBz1S5lavHfHVXyyucw/b7P5k=@vger.kernel.org X-Gm-Message-State: AOJu0YxR0OsIntWB2snbclWCM1TOV7WRPT4Su3qfSJfP9VxK/ZPz8laO R9x95oQdDO41sy/JlyQaV0m3ouapbEBj1jVWvDFW7Ds1phid0PqMTvUa X-Gm-Gg: AfdE7cmwMUNKElFI+ga/2SJOC3snDOzeVLkyQ6mvdnM9GmiEVXQo3hNheTgT6cYH/4q w/ypQpPnbYkuI2wpfuajHtUjHSNQCKMPPsE2dKxda564MhjlZ/qmDmn1Bd+WlnibxhdtfbdeIvI uUg4MJoQZYPG/4enCiaiYnSGpF48ma9TzyxvEVu8DLRstf0b7r6uUecSirokcjcJjCi/r1iMZkO dx4+0HWbR0ZMDptPE/SQY2a8EzNqa2nHGPqIEzoDk1TtXLvFlKKMJhv94JnH08nSQf8LSVVWa4J bPymRIwOfMJRWT6LLkfq4EepB3pJDHRHRGFp0/GMYyyt6LABfVCYinZvrfVwjkvOjcPSo2LwV8g 8SjfWllVRar7jaCzTn602KFwcXRdpYdVW1yOGbaoyPzhlHqYfiKRxAl7YVyfLJ45otvVHFkI0SD TZpZ7u7IkkjHS3VfYBLUutnSOCuzCAEjOx2yByHjaQczYelsvoxA== X-Received: by 2002:a05:600d:844f:10b0:490:b2c9:e284 with SMTP id 5b1f17b1804b1-4925b3b4744mr21760465e9.30.1782205821796; Tue, 23 Jun 2026 02:10:21 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49245bba787sm226309215e9.1.2026.06.23.02.10.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 02:10:20 -0700 (PDT) Date: Tue, 23 Jun 2026 10:10:18 +0100 From: David Laight To: "David Hildenbrand (Arm)" Cc: Zach O'Keefe , Thomas Gleixner , 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 , 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, Matthew Wilcox Subject: Re: [PATCH v2 00/13] Dynamic Kernel Stacks Message-ID: <20260623101018.789a4094@pumpkin> 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> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 23 Jun 2026 09:50:00 +0200 "David Hildenbrand (Arm)" wrote: ... > There was some (hallway?) talk at LSF/MM about possibly removing direct reclaim, > similar to how other operating systems handle it. Now, I don't know how feasible > it is (I guess devil is in the detail ;) ), or any details how that would work, > but direct reclaim was repeatedly called out as one of the main reasons we can > get huge stacks. > > So I guess direct reclaim (incl. compaction) is one of the main problematic > pieces. Are we aware of other scenarios where we (easily) trigger consumption of > larger stacks? I suspect some printk in error paths could get problematic. Especially if they involve direct writes to a non-trivial console (does that happen any more??). How much stack does dump_stack() need? > Wild idea: as a first step to test the waters, use smaller stacks on selected > kernel threads and disallow direct reclaim/compaction if the stack for the > thread is small? Or if there isn't much stack space left? Isn't reclaim one of the places that is actually likely to exceed the stack limit because it is unusual and won't be exercised at most of the kmalloc() call sites? One you get to the slow bits (especially ones that do IO) it is unlikely that a context-switch to a special worker thread will make much difference. (You might need to boost the thread priority based on the priority of the waiting process.) David