From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 9F84A14884C for ; Tue, 24 Mar 2026 01:06:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774314416; cv=none; b=kUfKDt9v/aUY7f6Spq+Rl5CMYVuumsASB9QeWy922YX09XFrmBVKhvAHP7bvoNuDlJijAAq+U6KMPVZrlWkZkwvvfC+RRJoISRnOybtPF2zW83g7htaOgDIg0LXyqWZesLNKJQBWMUOuj5nlDUXxdlneCcLN6k8tKSyfe8ZnlR8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774314416; c=relaxed/simple; bh=r/spkdbS+nCRV11ka5TrTs8t52mPb10JIK7VayfNYts=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=FupuT/rPlSY+FPAtnrLK/J4z1MGKY3QlyO9DwJzZWdhDivMyIzbFb5I0tTBitD7TlxVrW4praEwFWeYhc63GGP0CVqwcvLBW6QPl6QKABQ/kblLtzxf+J7Kyz21h2mlyGdRFrS1/oyYp1kdn7gb3B5fns/gDEOWLhy5gHU18SCE= 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=RH5+8bdX; arc=none smtp.client-ip=209.85.214.171 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="RH5+8bdX" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2aeab6ff148so27015ad.1 for ; Mon, 23 Mar 2026 18:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774314415; x=1774919215; 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=Ek0OOmYJXz2DUEhUOUCfjBLElBgWO+47553Bp8YdGh0=; b=RH5+8bdXvHb2o70LYg77fnwqhr92ioEq7dVEzjcafv8iwYGBVZtm7B0WYc42RELeMt LwXNOGE2onShFw1pprypmxEtb3m74ghIVYizTY7NP7SPJEutrv0sM8PXzOtvUP1Jy+jJ 4vO2D9eSIkqRsjRHT8JkQsTb3BF4IFXC8pV5rQkmIPTmHqZkPNkejHrACMG2jRX+cwfQ BRg297JqZAh9yFxAO1h22QTF0LaWzwJONY6RonkhSvriFfzV+buLnNA4rPBlTHBNnSmm 27XRzWA+yKBRplM11/XT2CC6IS+/2bcJRIUSIdliHmj9EQCz+tdN9yzTcGJxxRPd6omX 9CJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774314415; x=1774919215; 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=Ek0OOmYJXz2DUEhUOUCfjBLElBgWO+47553Bp8YdGh0=; b=f6IlUR4qjOU+2PnMssjKJZJdGAogPOOMPKbAJW6TD4FlErfh74zc58WjLpVxqqje8w zBciW4zceQpc6ZoYFy0AWJ5MOYfcX3IVVQov/F5jkh+BmSanO9VlgHtep58fqSDqEPGa 2UGzisVQU820e68rv2Ie+3X/ypjWQgeLssK//I5EYiO0Sn+Yg0kj4Im01GjPQorLBmEg qswrzVN4VMuKzrg33BFD23TuPeBwGEr3txO0iAiZxjzyRFGfoHnlHd9Na8E3kNfsJND6 ejLhiupy62XBF6Bx3x9kkZYzT/EZby/89NopvszvEkPJ9vvkC5Q9ntNoAut/V8Oo/GWA p3ew== X-Forwarded-Encrypted: i=1; AJvYcCWcrXJ1IBm2cW9mubevYmbOce4A4fW4K7SjFIGw6Enc0ZkNlCEoUMReNHv+NJ0Mf32BKN9U3Cz0Kl0bU/E=@vger.kernel.org X-Gm-Message-State: AOJu0YyuLSg8hZC3ZL1nT0mhrZ3cKPUJ+sCZUgj5HOkdhQkSMuQhakhY cjvIalSJkRDk3LRhfJpyH5TKnkHA4agQm1T17OwXhLpvpVzq4B1YdvE+VqgicexouQ== X-Gm-Gg: ATEYQzwuHGNYvluJzuI/lQ+mdXMgxHJpAXsYHLLR1yqEvjYTyAvvBHeFqtoDbR/EPsF EyyS3VXapY5ugvuecpsuM0+Cw22JaFDAkrVcRHnR8qzbwTECNXnybXB2YjfMTJx4NjeLB+Cstou TjNiuxJGKhZ+hFNVXLkPlLkwvZnVp4NI2c1s/737izKGDt2gvo0HGFaKGb4Ytugb6Pleg+X8JgQ oxQeJdAExYLaIurgW2ZuKZTFS4HklbU4h08t1fS1ezcpvpYppMNZDb4nGvV35kUro4fUZtkPgCo YdTzHoSAL5osCgzPDm51Zix+UKAztjCX9BU6An0z1WfHnameguqqYLd38bcZjtAGkwBZMmxzk77 3o/wFSIcCXdTp+CDia9/UKkqgz8OQt/A6oW3Uw/GkGOO7dAgTi44ftqV7JcldQDO9vEGh3a2RY6 GwUw0FsWuZQJbfmGig6F+dzDZuYIxsmUOafSUUqBH4/Bs38f/Bsf4YiImHMH/uKUf2iEHIVgHkT xVDYfNZoyBegvUxGa0+A5/qOG1CrgxfTn3jSdzIF1HAynOghLhKxA== X-Received: by 2002:a17:902:cf42:b0:2b0:7a9b:82f3 with SMTP id d9443c01a7336-2b0a53e6fc7mr1544185ad.8.1774314414282; Mon, 23 Mar 2026 18:06:54 -0700 (PDT) Received: from [2a00:79e0:2eb0:8:36e5:9ffd:34bc:bb90] ([2a00:79e0:2eb0:8:36e5:9ffd:34bc:bb90]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b083655474sm158353015ad.48.2026.03.23.18.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2026 18:06:53 -0700 (PDT) Date: Mon, 23 Mar 2026 18:06:52 -0700 (PDT) From: David Rientjes To: "Vlastimil Babka (SUSE)" cc: Andrew Morton , 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: 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 Mon, 23 Mar 2026, Vlastimil Babka (SUSE) wrote: > On 3/22/26 4:03 AM, 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 starts with a 10 second floor to > > begin with. 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 that are at least a second longer than the longest stall reported > > thus far. > > > > Signed-off-by: David Rientjes > > I think, why not, if it's useful and we can reintroduce it without the > issues it had. > Maybe instead of requiring the stall time to increase by a second, we > could just limit the stall reports to once per 10 second. If there are > multiple ones in progress, one of them will win that report slot > randomly. This would also cover a stall that's so long it reports itself > multiple times (as in the original commit). > I like that a lot, thanks. Since part of the motivation is to correlate userspace unresponsiveness with page allocation stalls in the kernel, we increasingly lack that visiblity if a single long page allocation took 60 seconds a month ago, for example, and we have to reach that threshold to report again. The original patch ended up at line 4839 here: 4833) } 4834) } 4835) 4836) /* Caller is not willing to reclaim, we can't balance anything */ 4837) if (!can_direct_reclaim) 4838) goto nopage; 4839) <===== HERE 4840) /* Avoid recursion of direct reclaim */ 4841) if (current->flags & PF_MEMALLOC) 4842) goto nopage; 4843) 4844) /* Try direct reclaim and then allocating */ Which looks like the right place to put it, but probably after the PF_MEMALLOC check. If we set a minimum reporting threshold of 10 seconds and only report system wide every 10 seconds, I think this will work very well. And, as you mention, this also reports stalls for allocations that never actually return. I'll implement this and send out a formal patch for it.