From nobody Wed Apr 1 09:46:37 2026 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 7DF633ECBFA for ; Mon, 30 Mar 2026 22:42:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774910551; cv=none; b=CLw6MmYCps7gZnUwOfWHMzAOyoTWN0nS0WE0xFPd9ZIIdgk+8Z2Fty/u5KP8VP7OeSML8km8y2igXJBhWK+8ztciD1wqOPWXSbZEOWVcsF/MAYp9DyOKm7M25kLnp4a31Q6vHSoNNIxFix8q9uawHdBPjO2VgKxgGRN8kwGlz1c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774910551; c=relaxed/simple; bh=1KXkk6hdg/EBsnUxi/nOT8u4yUoZihj/RHwXlKq3+ts=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=JJH3jS6w5iiS/YX+9TUqB12tGWt3wZNkeu6Ajl2vbafFixeJuOWFu5Qjoo3OW+drt1MzNvnSif3CCLsW7/nYR3Aiw/f7v5os7S09fVcmKFbSnSPBCcqGop9hnd1XnErJmY1LpfAQ79PH1hpNKeMIiOkLCFSJiPElY9GzMuOyDoQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=qbchkB7E; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qbchkB7E" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2b0b260d309so15705ad.1 for ; Mon, 30 Mar 2026 15:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774910547; x=1775515347; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=tISSsPnc5j391XAZvj80zu48QZMM8bzoocK5g49wH/o=; b=qbchkB7E+4fLbXPWnpSeno2LDkWKUxXUvlxM+UAmrKjvdSXa2MuDi1hjEpWzFDdRgG MaGfqLqh+rzdti2QpZ2Dr4ToVQ0IRYLKXy7WFtoVSb1AWnXafP1IIYKLpyG/7/Ab15rN +0iMrQ32iEI5NcaopfFvIN7flnFv7Mrbu2lbVglQ0xqq7jAREZOvL8JDtg/soPecGHIl vi/ICLEaYis7Ni21+4E0C3FglacWSmTzAxvzMARXn39zjZzmXlv6M1pbUnIYBwtWHJbP JVqWyMiIAsdaPeb+C7cBDHGZVWR9X7/yizW2zIxMjQ3fV8RRlMROnAb3xMV67ETCLO3v mZ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774910547; x=1775515347; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tISSsPnc5j391XAZvj80zu48QZMM8bzoocK5g49wH/o=; b=FnSDyxjjQzCbA0NJQf0K2AoL/gv+Li/5QMPBsqkIYQ1/QLlLtWjMSRI+OD5+xFIZ2m mrgKGhgmXJeigdzTXewJTIsqcCc0oA8EmUbeIdKt1zlO2U+yW45xMtwQ+IbycS//ticd hmDFkvDiTPzUFs2QwC+fXOtTmqoIEscCThRiyZsWOl9ldoYUukiH5FygvbnnZZ3qKfSJ CgN/o4UVXmA/xCcp2CA9sftlJKkhVkwY6mUwiC0kWLkEJ3Bwwu/Aa4DtY+XeXr1/xD6B PMj/qN+zES7+Yc8LNO6W7LAX9fu71TSeQFgc0lctP7xAspLEWbhTqtrVqMumPPkxsd0f EkLA== X-Forwarded-Encrypted: i=1; AJvYcCV+MWXFIZq4OGorJCyk1kp62XLPBVFpOaN4SEyUi8DI5fHHiM1hGEEcFQZ0vGxzbYULRKo86vjx0inUIO0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy21WD5xCOILXd9ZAD8RKX1U4W+6B1KmEeJYKT8/8UHrR2Nx2wg +lUhuZsN3k84HF0YxH3pR4xn5t55bRv/Y3WhZdvNiYZgM4HCs1X9vlY1cbolySzF4A== X-Gm-Gg: ATEYQzyWPNg5GBZAyqxKeSBrYAynELR6zj3R5FRpMUrmtuNfiJeqLDU4IBh42jRmrAA wwl3anNHdCjVx3zgjXiPqWZVzn/uCczm9VPVPEnP+itl+Z9gnhMjCPRcyMDuX2vEXTkTcsjwIAC Rh/s3a/+G1sW+031Y7L0QHujjoESSz3LTd/JvIU4EvjO7g7YZK2t+pfa+GJ2uCv7qMdVlCnfKZw rKzlxhtyUNMNZ307hHK9sCjMtr8xfN/+kWL4YhzJINkYfkTTVDf85yJ/bboCOckhb2fU8afyI40 zYnuYDVi+XhEB31/wFO5EmHeli+hippcr2P/+T/kMi7Oy9r7dMLKV7qzZw4gTJsEnLorMSacC3g KBmw6Kf8iBmKzVjOBMomx+c5MRbHEw8JrQ+5iZn5Ts4o6rH6ir44uz1H9GXL3sIQ5dtHQKSW8Ly BBe2MJWggTHZjHSYBokB3oW+mdflwl5s3UeJnFypoUqUJiyKSUbi4+bKdCacM6+6M8Le8CQntsv 2rOVaGcMb3oxsuIr/VNdsasa5e9hc+3t27fiLgPpL3dNrQ93RB9lw== X-Received: by 2002:a17:903:22d1:b0:2ae:575f:3755 with SMTP id d9443c01a7336-2b25f78bbcemr1493575ad.20.1774910546781; Mon, 30 Mar 2026 15:42:26 -0700 (PDT) Received: from [2a00:79e0:2eb0:8:bec3:8e5e:fca2:7852] ([2a00:79e0:2eb0:8:bec3:8e5e:fca2:7852]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b242765c7bsm92505995ad.49.2026.03.30.15.42.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 15:42:26 -0700 (PDT) Date: Mon, 30 Mar 2026 15:42:25 -0700 (PDT) From: David Rientjes To: Andrew Morton , Vlastimil Babka cc: Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Petr Mladek , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [patch v2] mm, page_alloc: reintroduce page allocation stall warning In-Reply-To: <231154f8-a3c3-229a-31a7-f91ab8ec1773@google.com> Message-ID: <58a10940-e44c-a120-dd6e-ee9f480c4946@google.com> References: <30945cc3-9c4d-94bb-e7e7-dde71483800c@google.com> <231154f8-a3c3-229a-31a7-f91ab8ec1773@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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") because it was possible to generate memory pressure that would effectively stall further progress through printk execution. 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. Acked-by: Vlastimil Babka (SUSE) Signed-off-by: David Rientjes --- v2: - commit message update per Michal - check_alloc_stall_warn() cleanup per Vlastimil mm/page_alloc.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -316,6 +316,14 @@ EXPORT_SYMBOL(nr_node_ids); EXPORT_SYMBOL(nr_online_nodes); #endif =20 +/* + * When page allocations stall for longer than a threshold, + * ALLOC_STALL_WARN_MSECS, leave a warning in the kernel log. Only one wa= rning + * will be printed during this duration for the entire system. + */ +#define ALLOC_STALL_WARN_MSECS (10 * 1000UL) +static unsigned long alloc_stall_warn_jiffies; + static bool page_contains_unaccepted(struct page *page, unsigned int order= ); static bool cond_accept_memory(struct zone *zone, unsigned int order, int alloc_flags); @@ -4706,6 +4714,40 @@ check_retry_cpuset(int cpuset_mems_cookie, struct al= loc_context *ac) return false; } =20 +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 =3D 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; + + /* Check again, this time under the lock */ + if (time_before(jiffies, alloc_stall_warn_jiffies)) { + spin_unlock(&alloc_stall_lock); + return; + } + + WRITE_ONCE(alloc_stall_warn_jiffies, jiffies + msecs_to_jiffies(ALLOC_STA= LL_WARN_MSECS)); + spin_unlock(&alloc_stall_lock); + + pr_warn("%s: page allocation stall for %lu secs: order:%d, mode:%#x(%pGg)= nodemask=3D%*pbl", + current->comm, stall_msecs / MSEC_PER_SEC, order, gfp_mask, &gfp_mask, + nodemask_pr_args(nodemask)); + cpuset_print_current_mems_allowed(); + pr_cont("\n"); + dump_stack(); + warn_alloc_show_mem(gfp_mask, nodemask); +} + static inline struct page * __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, struct alloc_context *ac) @@ -4726,6 +4768,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int o= rder, int reserve_flags; bool compact_first =3D false; bool can_retry_reserves =3D true; + unsigned long alloc_start_time =3D jiffies; =20 if (unlikely(nofail)) { /* @@ -4841,6 +4884,9 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int o= rder, if (current->flags & PF_MEMALLOC) goto nopage; =20 + /* If allocation has taken excessively long, warn about it */ + check_alloc_stall_warn(gfp_mask, ac->nodemask, order, alloc_start_time); + /* Try direct reclaim and then allocating */ if (!compact_first) { page =3D __alloc_pages_direct_reclaim(gfp_mask, order, alloc_flags,