From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 08FBD3C13F5 for ; Mon, 30 Mar 2026 14:06:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774879607; cv=none; b=oBiL1UtRrn8gIdsClo4T5BQ6nFFf0QOpY5yigMElkqZszxauEbusrj4LhfIbczr3fboDYJNauSefTSCyEmmpvbhcAzyPxLbcgMY0o8hQjozCJKUUvHz9pHKK88u9LL7s5pZ7oXwwQA9+SLrd5Ly0gMXlEaKb8RrcHmHarjs+DYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774879607; c=relaxed/simple; bh=Jdvssgs4SUj8FpK4EW+j0eGP5POHJYlB3JEjjf7pwKE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JGoZy5F5W/QUwzW6EYWYde9UTK6URNtMXYPIVOxabW59Lnjd3L5nXKd1xx+mPTO8PBo7i7LJehqCk1J7tx91rKWC/v2f+RdQjwgzj6poJ+1R7fr54MlO5sQKlYOXJM40wacsrOYQwidI1IujiWhp8xpGa/VEKsIAOnCXef6L5ZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VjF61byP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VjF61byP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE23EC2BCB1; Mon, 30 Mar 2026 14:06:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774879606; bh=Jdvssgs4SUj8FpK4EW+j0eGP5POHJYlB3JEjjf7pwKE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VjF61byPNpNACgloARyQCdxaU3bR64V0AyqlD82R4yHO1rdr7/SMbsxbtKG7Lu1kg UnfTLrtU6/1UpVjaJfLtDp50xvBDSS1wR2dzLsj9Pm4EWEZ+hCWf7+Ux/DsdjRD5zt azrsAe71VXV8rDfn+7fg9i7b+avTXd9MVPtG/aIIfN7Iax59QHFcg8GXPG1z9qyzi2 Yallxw8K9Amiqoc/YHw3RtavFx1BgBX0mEUAVjiBlKbWcN9sV+yRKw4y/+HuAvxGrE lctNJR8q1xAPO/bo//1vyD7q4dHy/Ml86Gjz2xUS1kAynHfLirFNGHnQCsbPqg0RqX daZe/aWslLjRg== Message-ID: <46a4a778-1ae8-44a5-b0cb-1b2c810d2683@kernel.org> Date: Mon, 30 Mar 2026 16:06:42 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch] mm, page_alloc: reintroduce page allocation stall warning To: Andrew Morton , David Rientjes Cc: Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Petr Mladek , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <30945cc3-9c4d-94bb-e7e7-dde71483800c@google.com> <231154f8-a3c3-229a-31a7-f91ab8ec1773@google.com> <20260329201733.6a4647ade4751e761034b9b9@linux-foundation.org> From: "Vlastimil Babka (SUSE)" Content-Language: en-US In-Reply-To: <20260329201733.6a4647ade4751e761034b9b9@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/30/26 05:17, Andrew Morton wrote: > On Sun, 29 Mar 2026 18:08:52 -0700 (PDT) David Rientjes wrote: > >> Previously, we had warnings when a single page allocation took longer >> than reasonably expected. This was introduced in commit 63f53dea0c98 >> ("mm: warn about allocations which stall for too long"). >> >> The warning was subsequently reverted in commit 400e22499dd9 ("mm: don't >> warn about allocations which stall for too long") but for reasons >> unrelated to the warning itself. >> >> Page allocation stalls in excess of 10 seconds are always useful to debug >> because they can result in severe userspace unresponsiveness. Adding >> this artifact can be used to correlate with userspace going out to lunch >> and to understand the state of memory at the time. >> >> There should be a reasonable expectation that this warning will never >> trigger given it is very passive, it will only be emitted when a page >> allocation takes longer than 10 seconds. If it does trigger, this >> reveals an issue that should be fixed: a single page allocation should >> never loop for more than 10 seconds without oom killing to make memory >> available. >> >> Unlike the original implementation, this implementation only reports >> stalls once for the system every 10 seconds. Otherwise, many concurrent >> reclaimers could spam the kernel log unnecessarily. Stalls are only >> reported when calling into direct reclaim. >> >> ... >> >> +static void check_alloc_stall_warn(gfp_t gfp_mask, nodemask_t *nodemask, >> + unsigned int order, unsigned long alloc_start_time) >> +{ >> + static DEFINE_SPINLOCK(alloc_stall_lock); >> + unsigned long stall_msecs = jiffies_to_msecs(jiffies - alloc_start_time); >> + >> + if (likely(stall_msecs < ALLOC_STALL_WARN_MSECS)) >> + return; >> + if (time_before(jiffies, READ_ONCE(alloc_stall_warn_jiffies))) >> + return; >> + if (gfp_mask & __GFP_NOWARN) >> + return; >> + >> + if (!spin_trylock(&alloc_stall_lock)) >> + return; >> + >> + if (time_after_eq(jiffies, alloc_stall_warn_jiffies)) { >> + WRITE_ONCE(alloc_stall_warn_jiffies, >> + jiffies + msecs_to_jiffies(ALLOC_STALL_WARN_MSECS)); >> + spin_unlock(&alloc_stall_lock); >> + >> + pr_warn("%s: page allocation stall for %lu secs: order:%d, mode:%#x(%pGg) nodemask=%*pbl", >> + current->comm, stall_msecs / MSEC_PER_SEC, order, gfp_mask, &gfp_mask, >> + nodemask_pr_args(nodemask)); > > Snould we use dump_page() in here? It prints more info, does the > snapshotting thing. But we have no page to dump, or did you mean something else? Maybe some part of warn_alloc() (without its own ratelimit etc) could be extracted end reused. >> + cpuset_print_current_mems_allowed(); >> + pr_cont("\n"); >> + dump_stack(); >> + warn_alloc_show_mem(gfp_mask, nodemask); >> + return; >> + } >> + >> + spin_unlock(&alloc_stall_lock); >> +} >> + >