From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 2741F2C11C9 for ; Mon, 5 Jan 2026 16:47:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767631667; cv=none; b=D5gNUbimB9vHLyEzxvr18/QiCFJmfccURKq59IR0bQcUtfVma0e2nAASAclCwxElmh9AJP7KCvsYPXvm8lRljwuU8r4iXl/amZCVxQsdpawZ6D/5OwtmUZ3deUbZB+fY/LTSReKFzuByMzwtwFxeHqr1emb6PSF2PloCXHwDEHc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767631667; c=relaxed/simple; bh=lGxf9h/shBUiOXjNLXwjzZz8fXrwcmxt9LyvkBkXDXQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cXQ0FXHCQx9T+z57Rd3ZryIgwlCaqQZg7Uli/1VBWHT4++kr9tJ8LU3W7kO0ubpee8APdxQkp9UxuAYoW4zuIa8bnYiW6WIaoWnwwJH1c3ZHF1sSDjOFRU6XDsheUj0G68mPKb0PY7o/zEaA/ONrGFGJsQiXwZvDmWy1dzDsqQI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=TfjaBuPL; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="TfjaBuPL" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-477619f8ae5so977435e9.3 for ; Mon, 05 Jan 2026 08:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767631662; x=1768236462; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=dVf3u2DFHBy+G2reAT7+xTPxrhj2Q9BCnr/QUBSKiK8=; b=TfjaBuPLUUV1GM9inyY9H4u5ubh4mr77uo2IlRdmGfSsTjZxJgoLHpGDBIgIuqpdCE gvaf2gbobTy8WnHE+FtGIC8kRkv1WSSlj2BGTc1hLIl/+aafpSwS7KClcRnmiqkcbkXs FxH0nR8nP0j4m0OsXw2SCQFTCyI6sF6khElQU90Dws2OMAxXuhRpcYZt8SYtWw9DRyqT yQjO7EiowIiHnnwhMQi6BbCVLNHdxJqjbNRQxb6cPZ2JspDVtTieYxtxG5zbviEh1ovO AxSgiIZ8eSUNLXDAQstsKLRt1t71Sf9DDc3bD2aPH/ypcjhu9JxpbihgJ7EcN979NAYu mQEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767631662; x=1768236462; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dVf3u2DFHBy+G2reAT7+xTPxrhj2Q9BCnr/QUBSKiK8=; b=PF0MBX945cEGzl3avONg4bMaL0JEmuUp16ySalnlkGTNvLLJrzc+p47ysBWPY+61S5 aAph84JOqFIFAOGh23py98TnKjwJww3jO8IG0UmO1m3pp3vt2S+VXcBkPcyhhn3XhzLv 8CdNHy4sXoNWfEF3wx+wcGezVPoa2yyhmdKPlHRod39FpZdkGYUJtVjl/zUoOUZQVXy8 PBsubeNOWMpLHkDfmHDZgTYAbxku0K8yxnne5a/h8CRvYgBatQrFlA0FChbPU9N0ssI8 4MsYFhSsa2erkU5MhwctA5ISGS7kzQ+adCMEpDp1O8rziwqiGmZYh0LMWl94Mz4Nvz53 ss7w== X-Forwarded-Encrypted: i=1; AJvYcCXfHEsC6/DDxvJFZSk7HbD+tOs8zS+08epruwdWqDvVJF/uV8kRJPlBngv/nVdE8YZXdZ2ssvpP9IerfTc=@vger.kernel.org X-Gm-Message-State: AOJu0YwSXfB+Nur8PlmB4mHsMNLXzUk9Vn2UbSmyAse8mP4OZZIb9Q/b C5HBcvUAqdhobBM15m61hvrJmxtcjOpkBeDHTlqllzQIVi4WsVHpD9yZOkq1W61Wtk4= X-Gm-Gg: AY/fxX5PW/EWEqhFxDUFJtQ6giv1tpWfRjK3eKdZwnd+sVpzj7Pz9oI3DVMgPxfbuYZ zfXdzvOgEzf4KLlHzeqaj4y8lPTaUO65NZVv09UTwvhjcsmBhRO7Rfheam6R6YnYqdFQNd2ENFL qj1z7CSCoRgkY7YnRFtEwfeLUo0tdS0I4Ww0Qo6DjXwhFFvX0svCzH6Qsn4epaAxPkAabF5iTeR OVAurixRkUnQ+7LbmEGpOmGkqAOBUd33lfuLDdVhNiRUAb2HAnSJJdZjlN8UVJ0hHDC2qtyTKEa MdlwXYv5JvICeU3UA4uWn8/pPdrxEEYyzMvWWmQV5irUfEjCkhwRobGZJaVpJkUleYTwkzpUnpF U2BAQAI1ttFGKNO1uyvY2Y0yymGIzsgcQESHcew4QtVX742oDJiCVosg+2K71mSrWtSaAqIuPkb 9SER8+AZDg/VxW7iGk2/MNPnPy X-Google-Smtp-Source: AGHT+IEbXwEOmbKLHAAdWfErBpN1iq2Thm7pkrNBOzof7I9+NvjlAAF1JhXxTvcoCCGSIEMhKFN87A== X-Received: by 2002:a05:600c:3b87:b0:477:aed0:f3fd with SMTP id 5b1f17b1804b1-47d1953b7b0mr684658085e9.8.1767631662427; Mon, 05 Jan 2026 08:47:42 -0800 (PST) Received: from localhost (109-81-90-116.rct.o2.cz. [109.81.90.116]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7ece8088sm3482295e9.0.2026.01.05.08.47.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 08:47:42 -0800 (PST) Date: Mon, 5 Jan 2026 17:47:41 +0100 From: Michal Hocko To: wujing Cc: Lance Yang , Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qiliang Yuan Subject: Re: [PATCH 1/1] mm/page_alloc: auto-tune min_free_kbytes on atomic allocation failure Message-ID: 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon 05-01-26 15:29:04, wujing wrote: > 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. The thing is that your approach is not immediate anyway. You are scheduling a deferred work when allocation already fails unless I am missing something. Which is too late as well. Lance has a good point that updating the scale factor earlier might help to smooth out the reclaim for the increased demand. > ## 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. Well, if the memory is hard to reclaim for kswapd and earlier wake up doesn't help out to reclaim any memory then is realistic to expect that direct reclaimers can do better on the min_free_kbytes (and watermarks) update? > ## 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? I would much rather start with a simpler approach and only make this more complicated when it turns insufficient. Scaling watermark_scale_factor seems like a more natural approach to me. Could you give it a try or have you tried and it proved to be a worse solution? -- Michal Hocko SUSE Labs