From mboxrd@z Thu Jan 1 00:00:00 1970 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 99D9F35958 for ; Sun, 22 Mar 2026 20:28:45 +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=1774211326; cv=none; b=JOm5unUDBeIjr0a3FBh0aegpMB4lNffOlmfi8lNKPNSwMXlMCm2oChsQlp7ikKuGEwaXcQUWxp962Miy3teFmTD0yno2lhicyY4f88mo+7QOByQmiNUOjQUe5r9V688kSHVaODBf/t+aROpi3gVxMZcehgH+BEVvhORD5bj35TQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774211326; c=relaxed/simple; bh=BY5AYamhI4whROpegO7BCwL9Z8guG3pZ1MatKYcK7F0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=sVlk7z7bEcFBeYv8/lpcR7hSiPmwwFY+J1aTHmYHl8O8cxgRXdBghdcIcm2fD/c1o7HungX6l6oT264ap71akXDB+1tjVeTxd5zlyW4M2QyEUz03HWyZOyRVVEEyspeSbn8L0Ji/rto0mjSe8IjcNB+Nr/Jedlcwq+4zLbMaYnY= 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=pH+GglIz; 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="pH+GglIz" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2b052ec7176so111105ad.1 for ; Sun, 22 Mar 2026 13:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774211325; x=1774816125; 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=J1PdHQE6n/XEgS/aLzCs8JE23f7fC+5Lz7QhgSafyz4=; b=pH+GglIz3wjJhk2i8jZTXqEUP9opkRHSPWE5iinYusmhkMZBxNYLbnqWbbTQ+uFH2p Ka0W8ME0jrd2iv9QcpQbZEUl+Dbu3NmCZCRNa6cv/szIoGGUpF7/npyOPNPR/nNf8m3t 4PVkLHMoMqKLQy6eX4xONMpj3JEb8HKRD8p3SV3bXU0FiPUWHqIVJ1B4eggsaWP8ApJ0 ImZchiW/rtBFR3xdpChANIHuf6QLCw+eCfbgHWdVTlGacTdmAqNSimJeuMAUrQ7SQz5k PXLUlKU9aS0Yo+X8ph+2XMcDAlM7svUMRhro5JV01EJQ5AyZeFBgVog5fTOrCpsQCMGC Um3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774211325; x=1774816125; 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=J1PdHQE6n/XEgS/aLzCs8JE23f7fC+5Lz7QhgSafyz4=; b=J1k9Se6Q2AKoLfFKKF5kVMu5G9oBdHxfcvA3H3q63wz/Vw/H5+iSoF+hauroxUKMYg Ekaa+CRxZIQq83tsjAa6EoBYd3XNOrZeo6S572DPZRwDojqk5nIGtQXJjsn8gL42qis4 W+qI9mCvnBqCfS2rAtYb/YJ8xmdp7+TEQIgWDTbhqj/gpXMPk3rCR5OyHAFUoZcgD7dc wbJW9/WUDt8DxxpkTKP4fsVlgO1iuTh6b0iB7/WB+L30CE35EUFqzYFYQiNehsGuLEej xAWmAMu95vy9fY9QDz1q1G4aoofIguUCI9Q7WYZGJh3IkV1mPRMjF2H2sbIiMNwkgm1/ 2oHw== X-Forwarded-Encrypted: i=1; AJvYcCVcPIwIGXxcB6jFAHzoPGzA+mnpRQFHp4ENTSoiOIZvnI7kU0zk4bX8BPG5do+rZ18/qqRABhA3YsW7dWg=@vger.kernel.org X-Gm-Message-State: AOJu0YzTnUIcYts6hq5tlltm5V8+GcNA1JxRY1Rhu5lyDxMhNK3Ro9qu JgXml2eyZO644+5v+QxAnNEZfhGi87GK/eQ38C7EP1tRkfLkigJovD3WPeWC+UcTjw== X-Gm-Gg: ATEYQzxcqoR354KdxYv/QOuy7hp3gvWh5+6BpHeKLIzg4Ubnx7GkQoGsj7Fk94F28LC vY+dYB/AwtPXKbqsomCSPyC3NKHdYqM+3W5e+O0DlPWVfLHRi72vMs5CuW7Pu3wgc4F/Rqy8NFe i4omiPPABYohp8BPWVMrkjiQCCaFAKxtGH+j4hOhG+zr2nt1ypCH23c/Ee6GbLsrOnlU+eYz682 DxVEMvKpu/+1zLyc759ucruTTGMBYFN4TvNpoEt0Hn0E8n+DaKHYlnPEMIGbRmKb8AzMP7ZuyZY 0fLA2qjl44pBf5DDwKV7aw/dneXs+l8Ai9aoSoJTCMoqNxjcvh6Ybh/iMke8k6/4msv63hWX60V +uGYZ9hv25AMwGHElPTTQavexud2dQF28sxwddCpRW28n7EBip8NaEnQnetwoVYwMI1euCWQyPt dVbr0eWkJgJPVASCJZwL7pdQYSZVEH5tAeJB/GyWG8SVSY/keGpWCWvYs283zMbbNzuF1Yh1G7w 3AbtwLflNf792lBz2Yr3k8Y59YPlzR5bJkRhuvvQpMxn9yIImwlCA== X-Received: by 2002:a17:903:988:b0:2ae:bf32:20e8 with SMTP id d9443c01a7336-2b08b4c7412mr3343155ad.18.1774211324484; Sun, 22 Mar 2026 13:28:44 -0700 (PDT) Received: from [2a00:79e0:2eb0:8:57c1:f40f:db28:455d] ([2a00:79e0:2eb0:8:57c1:f40f:db28:455d]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b083655474sm108495885ad.48.2026.03.22.13.28.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Mar 2026 13:28:43 -0700 (PDT) Date: Sun, 22 Mar 2026 13:28:43 -0700 (PDT) From: David Rientjes To: Andrew Morton , Vlastimil Babka cc: Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] mm, page_alloc: reintroduce page allocation stall warning In-Reply-To: <30945cc3-9c4d-94bb-e7e7-dde71483800c@google.com> Message-ID: References: <30945cc3-9c4d-94bb-e7e7-dde71483800c@google.com> 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 On Sat, 21 Mar 2026, David Rientjes wrote: > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4706,6 +4706,36 @@ check_retry_cpuset(int cpuset_mems_cookie, struct alloc_context *ac) > return false; > } > > +static unsigned long max_alloc_stall_warn_msecs = 10 * 1000L; > + > +static void check_alloc_stall_warn(gfp_t gfp_mask, nodemask_t *nodemask, > + unsigned int order, unsigned long alloc_start_time) > +{ > + static DEFINE_SPINLOCK(max_alloc_stall_lock); > + unsigned long stall_msecs = jiffies_to_msecs(jiffies - alloc_start_time); > + unsigned long flags; > + > + if (likely(stall_msecs <= READ_ONCE(max_alloc_stall_warn_msecs))) > + return; > + if (gfp_mask & __GFP_NOWARN) > + return; > + > + spin_lock_irqsave(&max_alloc_stall_lock, flags); > + if (stall_msecs > max_alloc_stall_warn_msecs) { > + 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)); > + cpuset_print_current_mems_allowed(); > + pr_cont("\n"); > + dump_stack(); > + warn_alloc_show_mem(gfp_mask, nodemask); > + > + /* Only print future stalls that are more than a second longer */ > + WRITE_ONCE(max_alloc_stall_warn_msecs, stall_msecs + MSEC_PER_SEC); > + } > + spin_unlock_irqrestore(&max_alloc_stall_lock, flags); > +} > + > static inline struct page * > __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > struct alloc_context *ac) > @@ -4726,6 +4756,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > int reserve_flags; > bool compact_first = false; > bool can_retry_reserves = true; > + unsigned long alloc_start_time = jiffies; > > if (unlikely(nofail)) { > /* > @@ -4990,6 +5021,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > warn_alloc(gfp_mask, ac->nodemask, > "page allocation failure: order:%u", order); > got_pg: > + check_alloc_stall_warn(gfp_mask, ac->nodemask, order, alloc_start_time); > return page; > } > > Another option here if we're concerned about calling check_alloc_stall_warn() on every slowpath allocation is to check this right after calling into should_reclaim_retry(). We'd normally be looping in the page allocator if a single call is taking >10s. That could output multiple stall warnings for a single page allocation, though, so in this case we'd probably want to (1) increase the amount of time between one warning and another beyond one second and (2) cap the output when some time duration is reached like 60 seconds.