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 B9F56C7115B for ; Wed, 18 Jun 2025 09:14:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AC356B0088; Wed, 18 Jun 2025 05:14:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15D716B0089; Wed, 18 Jun 2025 05:14:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04BA76B008A; Wed, 18 Jun 2025 05:14:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E203C6B0088 for ; Wed, 18 Jun 2025 05:14:34 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8A24A80EBB for ; Wed, 18 Jun 2025 09:14:34 +0000 (UTC) X-FDA: 83567960868.06.CEFDA3C Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.35]) by imf02.hostedemail.com (Postfix) with ESMTP id CDA0B80006 for ; Wed, 18 Jun 2025 09:14:31 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of xu.xin16@zte.com.cn designates 160.30.148.35 as permitted sender) smtp.mailfrom=xu.xin16@zte.com.cn; dmarc=pass (policy=none) header.from=zte.com.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750238072; a=rsa-sha256; cv=none; b=W0XQ3tIwVHwtAoWqgDTO0UyGFiStwrZZcYf5YFBaCkq+7j607b8BQGn56LupgFlDvUnlcC dTqMaTr2GPow8uwlylVzVhAQ/HqBHffpVhHTawV0sVW7zN+cCx9MDacr6nNhqeIe3MBned C+LSML8opfCwh4l5J82jF2pcUijePPY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of xu.xin16@zte.com.cn designates 160.30.148.35 as permitted sender) smtp.mailfrom=xu.xin16@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=1750238072; 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:in-reply-to:references:references; bh=TrJtacKlKsyFZ9uZT+Iace6NqpZG649npriaahy6X4M=; b=Hc+P5NDX5Ep0oUwMScLw7FHOiXMTktB2mfZpNBGTyxsB7liFSouuE8jrF01DSCoyUHxxAa k5EPIdDca2JpLm+GKacGH8kmH9+KMO/hiiJo4OptrEZ4nLoGg0fmAsYs7Gw74L4oYlFWy7 t7MCnkJPKTIYvYlhvCs6ETonPhyE2BU= 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 4bMdNL1MP4z8RTWX; Wed, 18 Jun 2025 17:14:26 +0800 (CST) Received: from xaxapp01.zte.com.cn ([10.88.99.176]) by mse-fl2.zte.com.cn with SMTP id 55I9E7Cx078308; Wed, 18 Jun 2025 17:14:07 +0800 (+08) (envelope-from xu.xin16@zte.com.cn) Received: from mapi (xaxapp05[null]) by mapi (Zmail) with MAPI id mid32; Wed, 18 Jun 2025 17:14:09 +0800 (CST) Date: Wed, 18 Jun 2025 17:14:09 +0800 (CST) X-Zmail-TransId: 2afc68528361114-19074 X-Mailer: Zmail v1.0 Message-ID: <202506181714096412Nvp5B3BkFpi3-CKLQ9ep@zte.com.cn> In-Reply-To: References: 20250606070314.3028593-1-xialonglong@kylinos.cn,63145e68-76f7-44a1-b3fb-1213eaa959d0@redhat.com,c6c628d9-5908-47f5-83f6-08d1621489fe@kylinos.cn Mime-Version: 1.0 From: To: , Cc: , , , , , Subject: =?UTF-8?B?UmU6IFtQQVRDSCAxLzFdIG1tL2tzbTogYWRkIGtzbV9wYWdlc19zaGFyaW5nIGZvciBlYWNoIHByb2Nlc3MgdG8gY2FsY3VsYXRlIHByb2ZpdCBtb3JlIGFjY3VyYXRlbHk=?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl2.zte.com.cn 55I9E7Cx078308 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 68528372.000/4bMdNL1MP4z8RTWX X-Stat-Signature: ymo6fqc4izzr4mdzzz417jcc8q36j85e X-Rspamd-Queue-Id: CDA0B80006 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1750238071-44758 X-HE-Meta: U2FsdGVkX18yofCJe2TLCJn0Xd9pF5Xga1GPUrBHSfgy+z+wyawBo+LTLwfK+FSnf2jCJRPwrpK/53I/W9WUL3Piu5RZRqgxTrvS3bgpaqSnGc6WvUkyzWh2XnTVF8y2qf8Gkx6NyawkpAEiFlnqILsl33LoqTNXCpjtnZNWManfmCh/F54vr/Ui3xyVlR7T0HxDc8Z42vUDcCV6ACRHZxSifHZ6qy4ru6miuwXbABOc5APCiKHbzNw3KkLExC3MJNWpcH2AG9F0qdnmF/x1u5EUeYryTNT794HbST1O3yix8Pizj1foKrGGEXaheNjMl+80w9d7WthYrOoSoGClNexEbLAjSCJ3dgbu6VqMUzPa7+fIoG09bFtCGZvMYupLWuBzhf8D2SB0DAynz87ege9/v3HO1Rt6EiB1oHyrgm6n3ZF8bIhXYCTIDvTVT97VrNUP4igg+wGiGBZrq7tbrgZmslAMejzAB+Pm2qKaV9UD3azZBfFGwdoCSMFd+D5Y7UUWv2l9wzfxlXfrAEyXVbC+2uZkA7DdKtvuIEPQmb+Sp45HCOm+ByrWBDTms71dzP4ScBI5t8PoXKBqDlQ5H+UmAq9vXbc27IQ8izKgQDME6N5+qFG3Y/n1U6+oPk8rZg4tTK1KP4h+un6m7/oY3ihTFGWLwA2uJtbq6ZUzxPBFTvpXMTmjBctfRfnlMJtriy+OlCxUoyOjzswD48dmwMUC09m6Y8ZWe2g/63l/jwwrppvP6IZA1JBASa3/D2QhaBfAvKbO3FXdDaBDZCtDnxLgnhEjnx4iSy9EsN3I7Jh5XflsPjFIJMjzMGZnFpy2saxzLeziyLQ98A0nI+WRFhH5qXWp/MJwHTt0omlVja8nbadiOFYCFFHO8Z8NAveqIFvcXie58iO6ViNEvMx20muUo08hzhDebncN3Vh+Z1rTj0ggkzSizFniqjlBsY3VaaGta2T7VG4aoFAq1Ad 64nmZuwm 2+mgwCLdYIwp7ijG2U/dzkMHYUtya8K1MBwGHMkyr8k1qYZODIAMEL94kchxt86EFjiCgWX9HteAV+uKNiLFDnjyrG+iWdwWVUYDlIsYDIPgwfMdya/d/EyWJuK7VgCKLmiDA4fz1DJ9/WwJBEXV8Fsw1xrWshem8ihc00ojNLwD4diLODL3tSYtN7fOQSyJ/H/IqW75KyWT7ObXe790TJnBRWrXrWnQKNtc6HUoKIv6asVxYPfNEK9vXclEMaKdENXPvTJ822RvG/3wPYm+LqQPHng== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000023, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > > >> and /proc/self/ksm_stat/ to indicate the saved pages of this process. > >> (not including ksm_zero_pages) > > > > Curious, why is updating ksm_process_profit() insufficient and we also > > have to expose ksm_pages_sharing? > > > Since ksm_process_profit() uses ksm_merging_pages(pages_sharing + > pages_shared) to calculate the profit for individual processes, > > while general_profit uses pages_sharing for profit calculation, this can > lead to the total profit calculated for each process being greater than > that of general_profit. > > Additionally, exposing ksm_pages_sharing under /proc/self/ksm_stat/ may > be sufficient. > Hi, Althorugh it's true, however, this patch maybe not okay. It can only ensure that the sum of each process's profit roughly equals the system's general_profit , but gives totally wrong profit result for some one process. For example, when two pages from two different processes are merged, one process's page_shared increments by +1, while the other's pages_sharing increments by +1, which resulting in different calculated profits for the two processes, even though their actual profits are identical. If in more extreme cases, this could even render a process's profit entirely unreadable. Lastly, do we really need each process’s profit sum to perfectly match the general profit, or we just want a rough estimate of the process’s profit from KSM ? > > > > Hm, I am wondering if that works. Stable nodes are not per MM, so > > can't we create an accounting imbalance for one MM somehow? > > > > (did not look into all the details, just something that came to mind) > > > Indeed, using the method in this patch to calculate ksm_pages_sharing > for each process to determine ksm_pages_shared > > can sometimes result in negative values for ksm_pages_shared. > > example for calculate mm->ksm_pages_shared： > > if (rmap_item->hlist.next) { > ksm_pages_sharing--; > rmap_item->mm->ksm_pages_sharing--; > > } else { > ksm_pages_shared--; > rmap_item->mm->ksm_pages_shared--; // can be negative > } > > rmap_item->mm->ksm_merging_pages--; > > > Would it be possible to compare the ratio of each process's rmap_item to > the total rmap_item and the ratio of the process's page_shared to the > total page_shared > > to assess this imbalance? For now, I don't have any better ideas. Although stable_node is not per-mm, if you really add ksm_shared to mm, it won't cause negative ksm_pages_shared, because the count of ksm_shared will only be attributed to the process of the first rmap_item.