From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3986DC25B4F for ; Mon, 13 May 2024 01:49:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9B2C6B020A; Sun, 12 May 2024 21:49:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4B646B020B; Sun, 12 May 2024 21:49:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A392B6B020C; Sun, 12 May 2024 21:49:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8AFA26B020A for ; Sun, 12 May 2024 21:49:22 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3F7DD140AA7 for ; Mon, 13 May 2024 01:49:22 +0000 (UTC) X-FDA: 82111690164.30.DDC2649 Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) by imf10.hostedemail.com (Postfix) with ESMTP id 996E2C0011 for ; Mon, 13 May 2024 01:49:19 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of long.yunjian@zte.com.cn designates 63.216.63.35 as permitted sender) smtp.mailfrom=long.yunjian@zte.com.cn; dmarc=pass (policy=none) header.from=zte.com.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715564960; a=rsa-sha256; cv=none; b=loeRBbTzPvpU/Ufhzr1TgCtDsX+5rfbPxwlHLuNIc1TjF7zT0OZzPWErLHnWsRNxUNRK/J xPlGVCSXOrjnx53R1vWixNq6cZ7O53HJFFnOC6wsxwrnnxLvJHkshvFYwyDXX2/V3DxTnv woNOgkV4AMGbuPnJeDCiUQPAccm2q+U= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of long.yunjian@zte.com.cn designates 63.216.63.35 as permitted sender) smtp.mailfrom=long.yunjian@zte.com.cn; dmarc=pass (policy=none) header.from=zte.com.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715564960; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references; bh=AgmoHPW1Kt2LXmd2HjKoI7QLu0LFgmGde3iZMzvHQ1c=; b=wte47IOeDOA8BQhJmksylbZRy43f5qlwZZFKHQ7e6tMC9VVjTuaZ7Z+Ap8VME7Xfc8wTE2 jhuul6G5+eTu5l1rw4Mb41WpLX9L5wp/2Xcz9qpoc/XSLn1hlTMwXZWofmOTS6zhe44T0p CP52U1xDkP8gXeS7NDJamrj6y7LoGP0= Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Vd2Tl3BQqz4xPBd for ; Mon, 13 May 2024 09:49:15 +0800 (CST) Received: from njy2app04.zte.com.cn ([10.40.12.64]) by mse-fl2.zte.com.cn with SMTP id 44D1n3Ec014212 for ; Mon, 13 May 2024 09:49:03 +0800 (+08) (envelope-from long.yunjian@zte.com.cn) Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Mon, 13 May 2024 09:49:04 +0800 (CST) Date: Mon, 13 May 2024 09:49:04 +0800 (CST) X-Zmail-TransId: 2af966417190ffffffffd29-0282c X-Mailer: Zmail v1.0 Message-ID: <20240513094904033EDcCrUwr6SiEbZC4kH08i@zte.com.cn> Mime-Version: 1.0 From: To: Cc: , , , Subject: =?UTF-8?B?SU5RVUlSSUVTIGFib3V0IE1lbUF2YWlsYWJsZSBjYWxjdWxhdGlvbiBtZXRob2Rz?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl2.zte.com.cn 44D1n3Ec014212 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 6641719B.000/4Vd2Tl3BQqz4xPBd X-Rspamd-Queue-Id: 996E2C0011 X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: 3heqtnjkmijambwpx353dqbgzcfkjg5g X-HE-Tag: 1715564959-729155 X-HE-Meta: U2FsdGVkX1/cqVVliyzFgERgQF4EYtwwZzmc3/uAVisq70fX54fBosD8YwL2FHNhKY2Y/35aT1wqey2hAqaar+FFK77ZChM8a1Tz7nw3Ch0nFSoXnF0HM7BXX5Rw655bPIKPf/3f8vftjcTxUt6NFJWWcJ/7Z4pKVqdbT1PwlkacRXsXMMCJ6IYDq4VzYgiidxE4CFIWcYFzGbmpPPPBzDtR5VZg9oHxBY/sAw4cT2Fh++AZ2nVnGDFiCpa4z5TmI63grzS6y82Xx4qUDDUjHbvgCqUSuFWHTwYmbmS82IS/vmV5bpXUS2c73zKBxrA+sYWYcK0TG7z8a4zBlI0A3uIMeNjL6Z48U/Muk9vEiLoL/5LweY4nQrkapU2xRjUeTpeZMgwYLD9ipDlWZIOtL4y6F8DFU2fA7ddHlsJ/1MmKOINPMI41NI+1KXGkSZxxMeDcQAoRYEN3FqatxJDd2ngIS3q5HA07k0ZK1b0H7loMwMqXsQkTPG5rTgmQdXY1sfFD6MwcsJ2AzlYBfrasPSDWJMcEGtdBQF6J5jLokz5S3QyQE3a2ieh8dBCf25QhYdlY+VbEW03Cw0+2bm2MhFyTiTQVBp+imaRw4hSRehtjxsH6rGz40et45FiZ0joisMoeFJs4FutpEY8I3yBeSG7t44SAkD1+PG+hSN/pvh8Iam7fHFNyVjVENl/WEjPK6ur1Jk1FXLYrEoHa3/H6wTTrLLhgHMOYQNLpd0TJAhBFYHBji1MUPIcXfEi4RGPDcNHgjv4ntU4wzZK57ElOIqaYIO4JX/0hJ0nQ+Tu0AwPymzcLrvvkDwWZMpa88FsvtJdI7AYJ4imQ8HN69udYRxpmv+tgOH09lROBw6jDcCk04+SoETjLMzMNo8jTK30miRjpbbFU06hDxGQpyMCJzGjzhJTIIsqScixLoOiKXtqhuqCIBlN/Y/9s2DI3R8FLtzC8KML/3k87DNny5ai 0gdRyLj/ 52fbVMJwL81jqbxvgE1GgD5bLL/tI7WtmnY4vBi7Zql4sRuRzkKnHnUWxrd2fjWsvWO//cZG9JiEmeID/16N1shrKhHvpPIo0nGrpbe9wMb2bc5DqYxiw+5IE3heSfNBOVKMOjkl14ddy6aLLnTxIA7W18C7xPIiUkk9EO/F/QPx3fBcLDF2Fy5GAKqYqBJbSgKPpb1Ehd4RuQu2VnQyvnR3ykEjz8w0X3MN2B1fFH7HdSOSyDYac14NFZw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hello, everyone, I hope this email finds you well. I am a kernel developer and have been very interested in memory management and related data statistics recently. I noticed that there is a property called MemAvailable in /proc/meminfo. It is indeed helpful to estimated the available memory of my machine. Out of curiosity， however,  I would like to inquire about some details with you: > Currently, the amount of memory that is available for a new workload, > without pushing the system into swap, can be estimated from MemFree, > Active(file), Inactive(file), and SReclaimable, as well as the "low" > watermarks from /proc/zoneinfo. 1. As described in patch 34e431b0ae398fc54ea69ff85ec700722c9da773, the estimation    of MemAvaild takes `without pushing the system into swap` into account.    Is this for performance consideration? 2. when I raise the memory watermark through /proc/sys/vm/watermark_scale_factor,    the value of MemAvailable sharply decreases. After investigation, this decreasement    mainly comes from the adjustment of mem watermark. Why shuoud we take the    change of mem watermark into consideration? Is it also for performance    consideration? Why the performance loss must be considered even for embedded    devices that focus more one available memory ?  3. Assume that the performance loss caused by swap is tolerable on specific    embedded devices. Is it more reasonable to use MemAvailable plus the fluctuation    value of memory valuation due to watermark adjustment as the true available    memory of these devices? Thank you for considering my inquiry. I eagerly anticipate the opportunity to connect with you and gain insights from your wealth of knowledge and experience. Warm regards, Jinhao Chen ZTE Corporation.