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 4FF78C77B7C for ; Tue, 24 Jun 2025 09:47:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F068F6B00AA; Tue, 24 Jun 2025 05:47:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E906C6B00AC; Tue, 24 Jun 2025 05:47:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D58236B00AE; Tue, 24 Jun 2025 05:47:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C033F6B00AA for ; Tue, 24 Jun 2025 05:47:23 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2DBE912060F for ; Tue, 24 Jun 2025 09:47:23 +0000 (UTC) X-FDA: 83589816366.01.A52203F Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.34]) by imf11.hostedemail.com (Postfix) with ESMTP id 79AF640014 for ; Tue, 24 Jun 2025 09:47:20 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf11.hostedemail.com: domain of xu.xin16@zte.com.cn designates 160.30.148.34 as permitted sender) smtp.mailfrom=xu.xin16@zte.com.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750758441; a=rsa-sha256; cv=none; b=fXLuYUNYnckMNrfTobwcf3fR4kmUadFuLj8KiWh4B9Y1Gm9vnYimvxg4atRXofhtG6VSp+ OSpdr1s4DMNIVtvZvpMPjP7kkGBKzUOdntILhpoW6JCbE4Fq+v2W3HVoMbprgJP3QPTfMN ug862Y3PKKX2sBNpkSif4KlKobkab2o= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=zte.com.cn; spf=pass (imf11.hostedemail.com: domain of xu.xin16@zte.com.cn designates 160.30.148.34 as permitted sender) smtp.mailfrom=xu.xin16@zte.com.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750758441; 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=WRrhOoIdiouNQ8SLugZFGHNZSI6pMZ+D65KCmybanPw=; b=A9pcWpX//w/jq1IyHDzoriH3u1Y8qF9TyuxGNs6Ekm2svbaqpl5C/2s9hV6XfjsvQcUYqG 9Z4lX/zqBEBd82VTz2F9QOZY+CsZ1JXrPHd0g0JkdedoLA5EUdnBqO1ntqmY3kFGJsARUy Z0ETsj6awZv1uwZtYkBQ+6X1eQPZs6o= 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 4bRKqT1h2Tz5DBq2; Tue, 24 Jun 2025 17:47:17 +0800 (CST) Received: from xaxapp02.zte.com.cn ([10.88.97.241]) by mse-fl2.zte.com.cn with SMTP id 55O9l9iv067596; Tue, 24 Jun 2025 17:47:09 +0800 (+08) (envelope-from xu.xin16@zte.com.cn) Received: from mapi (xaxapp02[null]) by mapi (Zmail) with MAPI id mid32; Tue, 24 Jun 2025 17:47:11 +0800 (CST) Date: Tue, 24 Jun 2025 17:47:11 +0800 (CST) X-Zmail-TransId: 2afa685a741fffffffffdb9-d505a X-Mailer: Zmail v1.0 Message-ID: <20250624174711752wxRCqiy0LZGukb1R7z_6D@zte.com.cn> In-Reply-To: <910a462a-8d4d-4b5d-941c-ba1396e287dc@kylinos.cn> References: 202506181714096412Nvp5B3BkFpi3-CKLQ9ep@zte.com.cn,910a462a-8d4d-4b5d-941c-ba1396e287dc@kylinos.cn Mime-Version: 1.0 From: To: Cc: , , , , , , , , , Subject: =?UTF-8?B?562U5aSNOiBbUEFUQ0ggMS8xXSBtbS9rc206IGFkZCBrc21fcGFnZXNfc2hhcmluZyBmb3IgZWFjaCBwcm9jZXNzIHRvIGNhbGN1bGF0ZSBwcm9maXQgbW9yZSBhY2N1cmF0ZWx5?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl2.zte.com.cn 55O9l9iv067596 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 685A7425.000/4bRKqT1h2Tz5DBq2 X-Rspam-User: X-Rspamd-Queue-Id: 79AF640014 X-Rspamd-Server: rspam10 X-Stat-Signature: tjemfyeqnzuon7op8arb71aofbi9xyrs X-HE-Tag: 1750758440-851694 X-HE-Meta: U2FsdGVkX19SEF97LR+gZP0PJLfZB0Ccl+8f9tjb62PrWZr0CoU1S53L1udNHhN7G5lYz57AIr6G/Mvwi9A/BU31O+CnkWYWr4eNVGgTSa3JzicAdj0IH3dL/V4Tvqxecl5ygKo09kTN6JOoxtIUwviP6GuC6JF2nOHt8Ej8l226+wlD07jUpsE4mrjvdNJOAxno20iy/q+hGoqtuHScDq8D/IUlDzT9yaqQubw3jtDzwTQ3sCD7vQnMMM+y/RFBAoW33PXj9+afXIQP7O0lokfS/mjkL+V04ABTEP1qxpd5Q7lvuf4jjnZVBJvVmvqrAdskFa+XbxhPTclM5RJhciTvea966c++PPS9JZEeiIMC2URAkSVJqsjR5667wDRV5fgubuOJZYcrN4FRXVOdHyVUjkACGzrQ9e2wTnNRbnpCpJKBXLUbgOYalT1FlLYwrYcrqGkMw4UE74V1s8AWkBIdVmEBbVHTxpk6v7650KdBZBm+/usGWSflO1IicdGScKwwBYUdCWLCy3vnYwW6+LQR2O4OJtxwCDpFF2IufwOm8CxdUQCwoaoatx87sQ97KgsSC0xxiqk6SKprDWyYlZySoSLZmyIOkuw1F/E5YlxwSuLZszip0pAdl+1guqWFZdwUlkfddvI93iY1DlQjQtk9dk3DcSRdRgfxmuEOqAGzHyV3o89J8Cr3Lv54rvUpBvXk1lCcF6ZhNPlp9AzmrBDMs+zRbh66THDyQPQmzY3Qc7PHS8u/N/vZEAidlF6I52n3UzfXbKq9MC7yCy6sS3f94p4Exu9LTRTesWs8x+m9ts+6eVMYa0ygIzI+VpKliWPpFQ3AFNpsKzD78EJMuvx+R/fMWk+Sm9iwK8/FEVmpEi+g+2YEl8SJLMr1iM38cjhDe/ez4nrSB5WVugST1rq8q75Mt07TL3w1dXFcP+TsVKZbzdhOeBqkHP+WpJGdshRTjbdfdgyl4Ls+YID 6KHGnVRE I0fQmIMVxellCEz6X8RJcjlHTY7+MfREZgAcCG8cWv6hY56/pS1TOmrq7+OGrUTgJDwk10nZR+iZa1BT5KBTjHNcIVDkMrI5AjEMdOtGidkmLKGWvCRCtDfnUhbCbQWA4NmtrdXyoWc/EOLQqhdAGI0muNwokA3wYH3KANxibX8iBEsQaIO7D6fzt658uDOzdp77oDMt0XcD/A7/0kXog2jVZpQnIZaQd/u8ahQviE3M9Bdc= 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: > >>>> 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 ? > > > Hi, > > In extreme cases, stable nodes may be distributed quite unevenly, which > is due to stable nodes not being per mm, of course. > There are also situations where there are 1000 pairs of pages, with the > pages within each pair being identical, while each pair is different > from all other pages. > This results in the number of page_sharing and page_shared being the > same. This way, using ksm_merging_pages(page_sharing + page_shared) > averages a 50% error. In your tests, I don't agree 50% error because your assumption that process benefit equals pages_sharing is fundamentally flawed. The issue lies in what is the most accurate definition of process KSM profit. Since stable_node isn't per-mm, we cannot calculate a process's benefit solely based on pages_sharing. The cost of stable_node should be split fairly among every process sharing this stable_node, rather than being assigned to a single individual. It's inaccurate to claim that when two processes' pages merge into a single KSM page, one process gains 4k - sizeof(rmap_item) while the other gains 0 ? This is unfair to the second process, as it actively participated in the KSM merge. The most accurate and fair profit caculation should be: profit = (ksm_merging_pages - united_stable_nodes)*PAGE_SIZE - sizeof(rmap_items)*ksm_rmap_items where 'united_stable_nodes' is (stable_node)/shared_process. This is too complex. For example: process A with one page is merged with process B with one page process A process B page page \ / \ / \ / \ / Ksm Page A: pages_sharing(1), pages_shared(0) B: pages_sharing(0), pages_shared(1) then profit(A) = (pages_sharing + pages_shared - united_stable_nodes)*4K- sizeof(rmap_items)*ksm_rmap_items = (1 + 0 - 1/2)*4k-sizeof(rmap_items)*ksm_rmap_items = 0.5*4k - sizeof(rmap_items)*ksm_rmap_items profit(A) = (pages_sharing + pages_shared - united_stable_nodes)*4K- sizeof(rmap_items)*ksm_rmap_items = (0 + 1 - 1/2)*4k-sizeof(rmap_items)*ksm_rmap_items = 0.5*4k - sizeof(rmap_items)*ksm_rmap_items > In practical testing, we may only need to enable KSM for specific > applications and calculate the total benefits of these processes. > Since page_shared is also included in the statistics, this may lead to > the calculated benefits being higher than the actual ones. > In practical testing, the error may reach 20%. For example, in one test, > the total benefits of all processes were estimated to be around 528MB, > while the profit calculated through general_profit was only around 428MB. > The theoretical error may be around 50%. > > If we expose the ksm_pages_sharing for each process, we can not only > calculate the actual benefits > > but also determine how many ksm_pages_shared there are by the difference > between ksm_merging_pages and ksm_pages_sharing of each process.