From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 2CFD539902B for ; Mon, 20 Jul 2026 03:38:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784518696; cv=none; b=nXfOqbFTHfYGNeSM+R+jzwC0IER4ENDzgXUzfJjqFIIidQ5PnDwfRu4ooYYLugjJ7Sy1fxx5FV9VYolnZB8I1hmkLj1ZNCaDU+fWU+fJ3vnQ4UQPOyUSuWWhaMsNqMmN/l7YDk2ycGE4s8wOvPmRqFhLuwPFXehk9kXBIN4v8VI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784518696; c=relaxed/simple; bh=2IYPYAaWLt0mLcr+u21OpJLddua6jvE6TZ5CKvfA5kU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ek3YsTmqNXoAXZsUQbX9Dz5MoMUhxKnxmFQ39c/feJDpSt/TGdEsloq9VFWlEYMpqZIA5t57W4gNeIYgbPuFW2/V/+sQqWEuTIbpRagEhWASADzRX1/i1aNyadQvnkCRGCowX26/m4TeP9Z1zkGRom7DcyN+Vu5V2BeM4ULQnKE= 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=lPBkBtWZ; arc=none smtp.client-ip=209.85.214.169 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="lPBkBtWZ" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2cc891373e0so117301905ad.2 for ; Sun, 19 Jul 2026 20:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784518693; x=1785123493; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2IYPYAaWLt0mLcr+u21OpJLddua6jvE6TZ5CKvfA5kU=; b=lPBkBtWZF2wCNviTunI5arUeBcn3MZxn4z6NQWDyJWe9kl169F5MWicasKH9xqrxf3 zsIZoOSmOEYV70Ue9GnrlTVtD4BAOI9g+v0w8NK2UIbPNN+gSxK6rNKr8xRkzJrDy10O ghRj2jT+ewtssWQoEJYYhES4fLNbRVLdYX81ta+drVGTJBQe0a9QLyauk0lymjy4AYls 4poKpo90Aj7q1T1KVLCnsHze/uS1pvdiRjQClFXtaA0608GFn1R1W30V/Op9kLbXOPgA WKRAacldbC4tfewACjdvusDPk3Wbc43Cx22D8+hZ6Ig0nZzitqobwjj79YoS7dVpQZWt 1ZZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784518693; x=1785123493; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=2IYPYAaWLt0mLcr+u21OpJLddua6jvE6TZ5CKvfA5kU=; b=qOq1XuKpjX0MwAJh/umAqjblDCczpISeyQM5EpCkJzEfVpX+uVRUYGJekWVg18mRMh yLn43S2a9AN+gU38lMIq0e2K2z6fyKENEcxTK7aUtEiwWIrYi0aXzEaZqIgyy3ALZAy9 uVkhBvf64sAh3ozN6WlP5GjAmoKuoHepGuEsb8hYKXq/PxjnfNivy6qiWMrC5A2J8PYL 32ADFR+ShimSNQOpQzeBD3t6rxjVyTcKmYVRKLaVIPQIF0MEGT9xEixhHPxJiCiitpET lEzK7ZnUPnUr9XKqtqgBwss7R1aPOprHN07A3ePCwL/ix+Wa1FxwBgcPs/ZoqwnZeyzQ Cm0A== X-Forwarded-Encrypted: i=1; AHgh+RqXuZAObZptVQH+BYF2rIawMpkuo14DiMb11rvKCvCtwTzkbhG7AxKRV7uCzH7YWnp6Y7S7BxQllRuZ1j8=@vger.kernel.org X-Gm-Message-State: AOJu0YyWDOGZyySVYj9hXwkL+iKUo86XYwDC6hzujS3jp+bWBec3DXs0 Kpo2KMor3u+ejCVnCrO/eRJWAWF9xcmeY4ldWgKz1dvYx7RaxsZAzhwU X-Gm-Gg: AfdE7cnpGzP0Pr8BL7giFcWhKFcVbLLUDs6Ua2gMtL3/Q97kVfd29kFbL4t3wkVmcat lNQugceW5HnHX81wHwxbEfibYgqbRnin2UvtMMIKpbBu5dS9zCmYMstH41WgjFrvzG7lYgo3ACn rfBp461IBaLDr91/2G5ErN2zAeyVLeyXZ9ajq7Dyb0QDveDw5q5buRtXvItMi3XyqjvtAQNeSXa 1TT4wHRomptSYyCV9hLgkYB6JimQHHqu8EXDtF3pnDk5O2ElYbVkO3cw/LdEFwX5GT283RECMdt TLaGAYjhEyalaAyN2R278clxgLdDQmR44PV98ZyABC16kYMPhlRym4Z9HjPanRSjap60YEbyllM Ar0HZcHb1KOwvBwC4SZUmzJNj5E5CGHdd3moKEMZAEIHtxM/sateUzsVAYygGVLo1ykRjQMk= X-Received: by 2002:a05:6a20:2583:b0:3c0:ac0f:6558 with SMTP id adf61e73a8af0-3c3ad677d0amr13026984637.2.1784518692673; Sun, 19 Jul 2026 20:38:12 -0700 (PDT) Received: from ubuntu.. ([23.254.208.9]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13ce2ddfb35sm26535048c88.14.2026.07.19.20.38.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jul 2026 20:38:12 -0700 (PDT) From: Jing Wu To: Vlastimil Babka Cc: Qiliang Yuan , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Axel Rasmussen , Yuanchu Xie , Wei Xu , Brendan Jackman , Johannes Weiner , Zi Yan , Lance Yang , SeongJae Park , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v10] mm/page_alloc: boost watermarks on atomic allocation failure Date: Mon, 20 Jul 2026 11:38:03 +0800 Message-ID: <20260720033804.3862547-1-realwujing@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: <20260214-wujing-mm-page_alloc-v8-v10-1-bdfea431fd97@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Qiliang Yuan Hi Vlastimil, Thanks for the review, and understood on taking the Ack back - the v10 changes were substantial, and I won't send v11 just to drop the tag. I'm folding it into an actual update instead. Let me answer your three points directly. 1) The Ack Yours is dropped. I've kept SeongJae's for now since he hasn't said anything to the contrary, but I'll understand if he'd rather it not carry over either, given v11 also fixes a debounce race in the atomic path that nobody, including me, had caught in nine prior rounds: last_boost_jiffies was checked and updated outside zone->lock, so concurrent CPUs (e.g. a multi-queue NIC spreading GFP_ATOMIC allocations across several softirqs) could all pass the once-per-second check for the same zone before either updated the timestamp. 2) Real-world benefit and side effects I don't have a clean before/after deployment number for this exact patch yet, and I want to be upfront about that. What I do have: a production host running a downstream 4.19 kernel logged 144 order-0 GFP_ATOMIC failures over a 4h15m window, every single one through the same NIC driver RX softirq path (bnxt_rx_pages -> net_rx_action -> __alloc_pages_slowpath), across several unrelated network-facing services on the box. That's evidence the failure mode is real and ongoing - it is not evidence that this patch fixes it, and I don't want to conflate the two. On side effects: the mechanism is bounded by construction, not just by intent. Each zone accepts at most one boost per second (the debounce timer), and watermark_boost is clamped to _watermark[WMARK_HIGH] / 10 per zone, independent of how many zones get boosted in a single slowpath call. Worst case this adds one extra kswapd wakeup per zone per second, and the ceiling on any single zone is 10% of its own high watermark - it can't run away or starve unrelated allocations past that. I've put this bound into the commit message itself so it isn't only visible in this thread. I know a bound isn't a measurement. If it would actually help, I can try to build a synthetic reproducer (fault-injected GFP_ATOMIC pressure under load) and come back with before/after numbers instead of leaving this as theory - let me know if that's the kind of evidence that would move this forward for you. 3) netdev Cc'd this time, along with Matthew Wilcox, who asked for the same thing on v1 and was never followed up on. Sorry that took ten versions. Thanks for staying on this thread. Qiliang