From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 BED424ADDBA for ; Thu, 11 Jun 2026 18:50:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781203845; cv=none; b=DMQNuiE9fbYi4gRYwQ/Pvq5OdZ2Qd58EiTKb8Gg4A6AFvyh9HWPYqDHJy8UyeEUdujLxe9Pw64z8o+v5cVXEbSDqqsrNGfkkQRptsmQlpSViosMj+dykOBOvNbuuIdkM5xm7o3ed6DwFEo8QvC8SHwqHJTH1oFiXdauICmJYl4A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781203845; c=relaxed/simple; bh=VUW8ZZgWRO6oBI/K1zuIFj0/8C/+Pr+bZK7RoXtN3jc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RYHZXS0LwFUzvEnP8llfFVaTx7VQf6XU92zMGv8Hz2sD75JTr+4E+G+Qi1nrrinWuswtdIwEBJVfZEzMe85rjZL5peoGaoiHzFiK3mvEZuQFxLHpwzyixJTfDtuemDg6RyzKudaryqQxsAYmHh9nde7F1R+buNHmCdYcYtBlFjY= 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=Lie2i9og; arc=none smtp.client-ip=209.85.221.43 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="Lie2i9og" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-45efb698ef2so80970f8f.3 for ; Thu, 11 Jun 2026 11:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781203840; x=1781808640; 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=aUxfWJt8IGWDlV52x/Qd1ZFtz3KlHMm4m7NO0v4ch/g=; b=Lie2i9ogPfH1ZoHC2N9n546V1C6nPnbyGDrutPigCWJqggUOezo+rKqd7SpAg7s+kS hKqI4ambdE+ZAHmqx587optL8xzq1ur+BIgrEnES+yzZy0RXweghDxd8P42IRbXOaxMH pBbA6VPdeEL/BOdwc5PADw6Q64u9ygsucZ/uBNh+Vl9bsN4mlNdOL1DkzhoYo5YrCYD3 /ctyrRpQg5xu+ReatLE+6XmGl/vaVC4Y96ZH0NSi1vWCpqvVw5wMJayNz+Zm2nPRaolM 713AlKg9Nlnro56hoxlHRy9YwtkXw2kfHDkPa/sU2jVf6dSS0PlRaFhtxtscVRoAJnG+ wL+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781203840; x=1781808640; 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=aUxfWJt8IGWDlV52x/Qd1ZFtz3KlHMm4m7NO0v4ch/g=; b=afvq1kCpYSrnfa6nKn7dKmgi9Vj/t9GJmTDoWxp5xgZ3EQhoeEFLwEs6eq1U6EG6n2 C+xUHizUNfEiZGv8raxJMx2pQsXHqPCyYpGafCoarKq9wWzCWSkpFNztkU8PL/zP/a/7 OTDmyV6jeRfIPd2h0VoBgJP4a7kRPNDRVYx9MCNu+zkZCr4GM9Yl3O1KNUW67V4FafTj 4oJkhghlpQxFLDPZ8wJfJDw1VN3QEA/OuSmcks0AnXnkZx7P95lo1kGOgRm6ALtdoLqv SXgVzLz5qpkGePrTICcGGraSMf/fpSaGBFgYragA/U3JX8KxyWN8Gv8glLawTexZg7cY y4DA== X-Forwarded-Encrypted: i=1; AFNElJ/3Ht1J83BY7wvWwOcjRtOOmkwTvbcjC36PTZ8rPrzBt541GmgYBiG+KFYLG8wzXHunZuMTgcy+3NTkMNI=@vger.kernel.org X-Gm-Message-State: AOJu0YxPHmERH1nfr7g0LaVJ9w8YW4Q7sS/j+VmcPd1GLIexlsp6hgnT niQnmZJQcphNQ8D9Fxr8S4cw6HohBQifqNFuVcaRKFb8bnk6KSpSg+h1Z8w6pjSo X-Gm-Gg: Acq92OHvKlAstrSAaNeP0S3WP8AtPgwA174ccO8WAtPQnUwcVRph7bGvvOfxks290OY /y+/4WasKcZRWQuCaKNPrWN92X+rKqwv63fAadrW7zc8hgSdrCIcBEbIoJNs3M4nI3Buy8A4Cka XmQqBhO9mdVzIrr2SRaGnBqkcIgZ/RYkTZ4PyQZ4fUg6JM8xcLNiNkO2jLYhH1Ufr8GFSIqOyQn zEjxA2hB/O4//JPJ6Y06a0TBQ8J86jT2M0Ysz4qn/MhU87sDgzx7yEzjjlT49DfKbrJi/y+qgPp NRI+2ZX011RHz5ehcLz96/DmAdDBQQ70vRSWFoKC7Hx6G2VCM0L70uglxl5EiscxBtGw1XvCjI8 mU1v71rgkjQfOa515UYDAUp/Z7VVvlPemtVh24wbZ+GduHzJEd1jVL39ffOQWSuFYIhUU1L8Frz hTnGjkr87c3DDJAxNo/qxB5W/PANB8H6KUBRa7SLN+kMTLrqkmNUKR7lAtR57b X-Received: by 2002:a05:600c:8b31:b0:485:9a50:3370 with SMTP id 5b1f17b1804b1-490e55c3ca2mr57651865e9.8.1781203839529; Thu, 11 Jun 2026 11:50:39 -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-490ea7c09bcsm3579135e9.2.2026.06.11.11.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 11:50:39 -0700 (PDT) Date: Thu, 11 Jun 2026 19:50:37 +0100 From: David Laight To: Arnd Bergmann Cc: SeongJae Park , Andrew Morton , Nathan Chancellor , Arnd Bergmann , Nick Desaulniers , Bill Wendling , Justin Stitt , Ravi Jonnalagadda , Quanmin Yan , damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: Re: [PATCH] mm/damon/core: reduce kernel stack usage Message-ID: <20260611195037.1adec04d@pumpkin> In-Reply-To: <20260611125704.3386176-1-arnd@kernel.org> References: <20260611125704.3386176-1-arnd@kernel.org> 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 Thu, 11 Jun 2026 14:56:57 +0200 Arnd Bergmann wrote: > From: Arnd Bergmann > > The main thread function has recently grown to the point of > exceeding stack frame size warning limits in some configurations. > This is what I hit on s390 with clang and CONFIG_KASAN: > > mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than] > 3440 | static int kdamond_fn(struct damon_ctx *ctx) > > The largest stack usage here is inside of the kdamond_tune_intervals(), > so by marking that one as noinline_for_stack, the functions individually > stay below the warning limit, though kdamond_fn() itself still uses > hundreds of kilobytes for some reason. Does that actually reduce the stack use if the functions are called? Or just stop the compiler bleating and running the code is still likely to overflow the stack. I keep thinking it should be possible to get (say) objtool to output the stack offsets of every call. With (I think it is) fine-ibt the hashes can be used so separate all the indirect calls (although you might need a 'salt' to separate the different 'void (*)(void *)' functions - that probably ought to be done anyway). Then it is a SMOP to generate a maximal stack depth for each function and to detect the recursive loops. I did that many many years ago for an embedded system (no indirect calls), the outcome was that we didn't have enough memory to allow for the worst case stack use! The deep places were all (the equivalent of) printk() in pretty impossible error paths. -- David > > Signed-off-by: Arnd Bergmann > --- > mm/damon/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/damon/core.c b/mm/damon/core.c > index 265d51ade25b..69f38c48ac08 100644 > --- a/mm/damon/core.c > +++ b/mm/damon/core.c > @@ -2002,7 +2002,7 @@ static unsigned long damon_get_intervals_adaptation_bp(struct damon_ctx *c) > return adaptation_bp; > } > > -static void kdamond_tune_intervals(struct damon_ctx *c) > +static noinline_for_stack void kdamond_tune_intervals(struct damon_ctx *c) > { > unsigned long adaptation_bp; > struct damon_attrs new_attrs;