From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.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 05E62221DB3 for ; Sat, 1 Aug 2026 07:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785569789; cv=none; b=FWY7E9ZGfjbzOtVAFAWQmhE2DiHYIVALwEbTk3wrLbPiYNbS9ZQdu8XZs4rx0t9yszbeAgK/EI0Iy+gRAsHBQmNTlcturXe7HY+AoFDXB4aWXoBejzq+dn1YXBBxp23z4t91C33xpA/jVCWh4d7aL9O+G83uyrDO7G4D3zQ3/qY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785569789; c=relaxed/simple; bh=UsSPyxUficWpUh44x4K2InTtUVH7ArMUL/fmmiuUnx8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cV8R9KWin5EAjMETK4ZUrcpUpBuCOZPw8HkVahGWjHZhZjKAEZQjLUr4Cca73r61JqHoPei1ZuP1hJciqWHikH/6Z6F/x4LbcP4lL5MW0DjrK5SIWmFbySly8nWm+TALRkqlwkkTxi3k2stIQdFq5EqD1fRQS10/lc72/WCR8nQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=ojW5ULwO; arc=none smtp.client-ip=209.85.160.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="ojW5ULwO" Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-51c2149571dso15867791cf.3 for ; Sat, 01 Aug 2026 00:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1785569786; x=1786174586; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=kJBAotesoPitI8Ljxfl5aXuisDO1RYNb9V1dDpCG1LY=; b=ojW5ULwOL0UNbu7G7Z2rI2P3IrP7NKblx4isyRaWKkrfecR1A7abO428S4xChJ20oU dVGv0Nvic/AMWmbSe03UBIfxxjn4ZqvkZle9L4345NtV+6W1AuJPQZq7bQq1J9uVE4c9 1a9LYkBrY0tPw5AZMVxE8K6wJW/GrGlejQLo4gRha1ia5YTVFDF5HFl9cH6GPoPwijHU amdXip2cVwukGvDGVeRQjrv9Dp6FQ8xCCpTduEBWFOKuv65QxqKDWCFDkKlJ3pB1avjR 1I/R4Tc2Ck0FwEb6hEw4CLJA2POJglP01cS6lBg6DtlXU8i92jor77i/RLwbqlSLJwiq 6UaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785569786; x=1786174586; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=kJBAotesoPitI8Ljxfl5aXuisDO1RYNb9V1dDpCG1LY=; b=B9O9ULtvnpdu56u8hqJXa4A+0zwR77c5AtzGddWjDvDzn+lCsCPyD3MxHbZJztSh9A mf2pDiHsEv3xQNyl+Rc3UsO3mqMc2oVtniRu+AP7hfw4ZBe23rkbLNqWDIUL8OWAMaa2 SLIaD0xgMYEuyVaT359CnrhThto5aUrHa8BqJczHYHj5KcbCG+Z/YAccxmHzq3vyfFbf V9YBLLRyd3xBgueC0VDl+FaMHoYFaJzx9tiZStoMawUsAOZKBzRF53PHVzS+fiCJLvse E2T4aGVoBZ0XUBlIjXWe02dxZQKGKEZdcvw5OeOUr5GOCMYMT7D+UEgJ8NZvO2pUC21x iKhA== X-Forwarded-Encrypted: i=1; AHgh+RqXUPrcNjXxH4baXNwhHHdJrEM/CDBJzVx2gA24SvcU1zp6svh/+L61W1ufhM+kO993cC6rQn+I2VTqgtA=@vger.kernel.org X-Gm-Message-State: AOJu0YyUBchdzr97hx37qQwZ19cC0Mh9T+y0eFKAwzlQTb/UKg/smS3k /tbPl+OXbTrynVJMwLsCkiEExhH3Be4COdmkKoYf0wRmdNyN//M1zr3Zz1FEg/lpL5s= X-Gm-Gg: AR+sD12m3AdlcJBpIBPdbH8qt2TzoF98DtyRWhz+4FQgDrVSuwxtPyuEbeI36f7GduQ An/naZHrDDPEeOML7YsY1nwU3eppQFCc+nIRQWhHKMaENX3p3Jwp1+6r322DCrYkvDz1uEsgjmI wUsZ3EzT1jlsHoP0tnD2WrSVv1AGtot4wkpWRO97cJNczmYxHEjcJ3yGM89C/WkerGm309DYCmO 0UIrEQIBhAUm11hNsbR6Tt0z2mLqptbJ3FQ6IW6VEhTpLcjFnyVVs9vg2na3yn9CR/Us4Sj7+HJ qjW5uNEbQjAVsdbojxOL+KlAYQXu4eEnZGMcktgn7UknVgSjWszzdLhBxoPJcJsV4Sk32F/d54+ CLVvRxflUhjdpG32QQOHIWj2SeidzigdXzGPL/Y9FefxFghZhceNKyKKuyUStFCo0oPKwU6goA7 1wNcBF9UpSlV7XBitaviPOfmiZhW9VRjp/uSgI/UCcC2HVcHFlW6vI6sof0UAH5MP1MW2ko+E= X-Received: by 2002:a05:622a:5906:b0:51a:896c:9aae with SMTP id d75a77b69052e-52b566ae2a4mr62282481cf.13.1785569785716; Sat, 01 Aug 2026 00:36:25 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-52b4e7ee1c2sm23439281cf.1.2026.08.01.00.36.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Aug 2026 00:36:24 -0700 (PDT) Date: Sat, 1 Aug 2026 03:36:19 -0400 From: Johannes Weiner To: Jianlin Shi Cc: linux-mm@kvack.org, vbabka@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_alloc: only update lowmem_reserve_ratio on sysctl write Message-ID: References: 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 Content-Disposition: inline In-Reply-To: On Fri, Jul 31, 2026 at 11:42:26AM +0800, Jianlin Shi wrote: > lowmem_reserve_ratio_sysctl_handler() ignores the return value of > proc_dointvec_minmax() and always calls setup_per_zone_lowmem_reserve(), > even for read operations. > > Reading /proc/sys/vm/lowmem_reserve_ratio should not recompute per-zone > lowmem_reserve[] and totalreserve_pages. Only do so when the sysctl is > written, matching min_free_kbytes and watermark_scale_factor handlers. > > Also propagate errors from proc_dointvec_minmax() instead of ignoring > them. This appears to be the primary user-visible effect. You send in "birds are real", function returns success, values are unchanged. After this patch you get a proper error code on this lie. > Drop the manual "< 1 -> 0" sanitization loop in the handler and set > .extra1 = SYSCTL_ZERO on the ctl_table entry so proc_dointvec_minmax() > enforces the minimum on write (suggested by Vlastimil Babka). That's a nice cleanup. > Compatibility note: > Previously a read also sanitized sysctl_lowmem_reserve_ratio[] and > called setup_per_zone_lowmem_reserve(), which rewrites each zone's > lowmem_reserve[] and recalculates pgdat->totalreserve_pages / > totalreserve_pages (visible via /proc/zoneinfo "protection" and used > by page allocation fallback and dirty-limit accounting). After this > change only a write does that. Documentation describes the meaning of > the ratio and the derived protection pages, but does not document any > read side-effect. > > Worst case for odd userspace that treated a read as a refresh of those > derived values: lowmem_reserve[] and totalreserve_pages remain at their > last written/setup values until the next write of this sysctl, or until > another existing updater runs (e.g. adjust_managed_page_count() on > managed-page changes, or init/watermark setup paths). Until then, > allocation fallback into lower zones and per-node dirtyable memory > (node_dirtyable_memory() subtracts pgdat->totalreserve_pages) may not > reflect a refresh that such userspace expected from the read alone. > Normal readers that only consume the ratio array are unaffected. I don't understand this. Nothing actually changes? It just runs through the calculations pointlessly, but using the same fixed parameters (zone_managed_pages(), lowmem_reserve[], watermarks*). * modulo the boost effect Vlastimil points out aside. Which seems worth fixing but it's a separate patch So IMO the changelog should be: 1. Actually return error on bogus values - i.e. check if integers were parsed and bound to positive range instead of silent rounding 2. Don't pointlessly recalculate on read when inputs didn't change > Changes in v2: > - Add .extra1 = SYSCTL_ZERO to the ctl_table entry > - Remove the manual sanitization loop (negative writes now return > -EINVAL instead of being silently coerced to 0) > > Link: https://lore.kernel.org/linux-mm/tencent_FFD4F4D728AAE8A8AE0AF277A59854A29A06@qq.com/ > > Signed-off-by: Jianlin Shi Code looks good to me. With the changelog fixed, Acked-by: Johannes Weiner