From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out162-62-57-210.mail.qq.com (out162-62-57-210.mail.qq.com [162.62.57.210]) (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 AFE8542AA3 for ; Mon, 5 Jan 2026 07:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=162.62.57.210 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767598180; cv=none; b=SjW5C+FZ7u1LEZljOrSQOy3UnMgVW4jQ31bdP4HZVSltyL5so1aZVW4A3IPwdQ6ZbpOZ1HjmUdDRqP9BbyQl6p7f+7VMuJ4VHymQ53qWNNt1gy3okUrPnnrSRd+34fuQuGdkUByJTQ2JHrHEXYO/hgGcBVvM9pgXn4kwZKji5sg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767598180; c=relaxed/simple; bh=4CKmBWphwqHQLuhd3k8ehRYd41Z+qUavJl4bYc93dss=; h=Message-ID:From:To:Cc:Subject:Date:In-Reply-To:References: MIME-Version:Content-Type; b=p79TUG/fzxKJQ/ZuydsHragg1dI3TA51FCUB0s3FfC0irv7YGyN1fBu37vbTSVdwJMfi1Nt8AzyfdMyOkAzgXed9OfY6QIoDtTlSwRQWDF+dY5BwrNjTkA6ohzBU0V2NM8iLQqMO33bdO55NhpJ5ePXvwcl4eqrN9f0XibCdKxw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=UNcXnX5z; arc=none smtp.client-ip=162.62.57.210 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="UNcXnX5z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1767598172; bh=l2dTv/FNr5ZBYUYJFBjrwwsOib3XHe+T921gUuHMQXY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UNcXnX5zEGPcaXvQXPhs06D1/aQQXberSNaTE5LKiKwaEvjrr/Djfy/w56aIT2QRv Valu61uZCUK5b4ZdjNJztz1pBjkzXPmzydhbUeNbbkVFWpwFAFtj1uRUOhRU/vH5+3 KJb5JvPCnNzf4JMvkntU+npUFnlTaS+hSloytAlQ= Received: from localhost.localdomain ([61.144.111.35]) by newxmesmtplogicsvrszb51-1.qq.com (NewEsmtp) with SMTP id 75D3C6F5; Mon, 05 Jan 2026 15:29:29 +0800 X-QQ-mid: xmsmtpt1767598169tnojks7dx Message-ID: X-QQ-XMAILINFO: NbgegmlEc3JuJvoeLQeVKYia9J1U4yJYBOq+Hs3nQSkJdJy1wM+tCIbcktScox NjqviY2TdsPPF77D5afaco96fcLMdjKMemSwgF+Wy9tcxENaQP0mhRYSn3e/cL9P0fn369uAszqb TDUaQigd9SDOvixQRUZTYSIeJWlfL1/MWlDAY7t/DI4xBonNLkLDwKW69lSJPAY7vGPyBhffFEgC OQRx+SWcy5+euka0aW0Kc3Y0ERP7czOnzPCNXzYxPqxRyeDyRZXpQ1qcOD4OP0UNcNsAKUECpy5a XjvxNFBqIXnC4iwnE6Zjfh9gwLbu0xsu+J/wiAWP7xvhToVYAO3BWId2+mCKzcYeG7fD5/CMhWTa MMqa1bXsHinhH4aQSNlwsboCwmblld7wR6X4KZLt6ZHqsYQr9OODQ9OfetSbaTkqDZ8nOBv2Us54 zP1pxcwYc+ZShobEnobfKU/hfpbUIoqRkHOgVsNRJs27Dz5YAHAfA49ZTSkoqFpMFZovJEgBO6tc sxMA40/i9DoJcsxDVMHC+WmPUiu4t90+0os2m5fzXMU6bLt/ejt77c4glImQ17hpIwRk9q9ELKVC TBTEXW5xjYhu2MHRf8HpptJbxIB1cqHX+Cw6AxQCSWoYKQgM0nd5OUR24B1A1mBhFSv15lnNGj5P GkiZKeQDpjjPjdq9rsYyC+TATUJTSTcuQ86yo0EIGjyY3QZgNgeTR2KCcsV+5NoAWJhZvEtUwhGI GK0Ch8Md1P0st+UXG7VyV6fZ2q5WhKdhQUKysMcdWuIadHAh7c7qGTYLgVrJ9JDsfSMtiaBOWrlu mazaYWv4RKLICBmHQ1AXzK17uyt2CIH3S8ZquNW1HOvloqkj3QOnCLjw0lc8PBn3/tOERp3cVzKE 6WsPAAm/Ax+xq3A72rIDgXz5Zg8wN8PTZw2P4qKCS4OUmxCPEG3vLJsMikKoLH7nZWo5CICmN6mA v50DlyoN+qCURMDmsSwZKk3pTS7/6f30MzBoJ/QFYbWSfetdPs3p2sS9xSpMkqrzCzvc8Fl3+on0 dHNWLtbPZmUvFhTDpF0mDWAke+0y5sBk5sLqMcdw== X-QQ-XMRINFO: MPJ6Tf5t3I/ylTmHUqvI8+Wpn+Gzalws3A== From: wujing To: Lance Yang Cc: Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qiliang Yuan , wujing Subject: Re: [PATCH 1/1] mm/page_alloc: auto-tune min_free_kbytes on atomic allocation failure Date: Mon, 5 Jan 2026 15:29:04 +0800 X-OQ-MSGID: <20260105072904.1298002-1-realwujing@qq.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260105063830.15140-1-lance.yang@linux.dev> References: <20260105063830.15140-1-lance.yang@linux.dev> 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=UTF-8 Content-Transfer-Encoding: 8bit Hi Lance, Thanks for the suggestion about using watermark_scale_factor instead of min_free_kbytes. I appreciate the feedback, and I'd like to explain why I believe min_free_kbytes is the correct knob to tune for this specific problem. ## The Core Issue The failures we're observing are GFP_ATOMIC, order-0 allocations in interrupt context (network packet reception). From the logs: [38535649.655527] swapper/100: page allocation failure: order:0, mode:0x480020(GFP_ATOMIC) These allocations: 1. Cannot sleep or wait for memory reclaim 2. Can only use memory below the MIN watermark (the emergency reserve) 3. Fail when even this emergency reserve is exhausted ## Why watermark_scale_factor Won't Help watermark_scale_factor controls the distance between MIN and LOW watermarks. It makes kswapd wake up earlier (at LOW instead of closer to MIN), which is great for preventing memory pressure. However, for GFP_ATOMIC allocations: - They don't wait for kswapd - They only care about the MIN watermark itself - A larger LOW-MIN gap doesn't increase the atomic reserve Even if kswapd wakes up 10 seconds earlier due to a higher watermark_scale_factor, network interrupt bursts happen in milliseconds, leaving no time for reclaim. ## Why min_free_kbytes Is Necessary min_free_kbytes directly controls the MIN watermark — the actual memory reserved for atomic allocations. Increasing it immediately makes more memory available for GFP_ATOMIC, which is what we need. ## Alternative: Hybrid Approach? That said, your point about side effects is valid. One option could be: 1. Increase min_free_kbytes for immediate relief during failures 2. Also increase watermark_scale_factor slightly to make kswapd more aggressive 3. This could reduce the frequency of hitting MIN in the first place Would this hybrid approach address your concerns? Thanks again for the thoughtful review! Best regards, Wujing