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 5FE2BC433F5 for ; Thu, 29 Sep 2022 11:34:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF0368D0002; Thu, 29 Sep 2022 07:34:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA00C8D0001; Thu, 29 Sep 2022 07:34:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8F228D0002; Thu, 29 Sep 2022 07:34:32 -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 A5CD18D0001 for ; Thu, 29 Sep 2022 07:34:32 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 740B71212E7 for ; Thu, 29 Sep 2022 11:34:32 +0000 (UTC) X-FDA: 79964915184.04.47F828A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id F3A20120003 for ; Thu, 29 Sep 2022 11:34:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664451271; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xlKGV7zI8yovT8Qjaw1ezWS3Z9lVHmoWfs71GWUdoy4=; b=XPuGtjI+uWbWYDDeNtt21VO/oybFUOHidW5all2oCrbj/Nd1Nsq2CV1TYyuKFGsIXFCYKG GuvKq/KD4fiR8T0zeRQ3sjXxyJoEbh2b7e5pAMQdipmSjBK9eOcMSPgpFpM+N8SS0v5lXg WPyIKOeDnee+207fYEWEFGJCZH+huFE= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-507-xY0-hYHgOlasxRE8F6Fjkg-1; Thu, 29 Sep 2022 07:34:28 -0400 X-MC-Unique: xY0-hYHgOlasxRE8F6Fjkg-1 Received: by mail-wm1-f70.google.com with SMTP id c3-20020a7bc843000000b003b486fc6a40so344450wml.7 for ; Thu, 29 Sep 2022 04:34:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=xlKGV7zI8yovT8Qjaw1ezWS3Z9lVHmoWfs71GWUdoy4=; b=cACEfmMV+2Y5gxrZp+cCAxM2ZGjhKWbdyIgU7HbTdPU17Sy26xB1bCJiKeIc7FLg0E PCP/l/JJvaEz8wE58WOlzZatt9jRXdEZj7JG/TFj70mv7ILKcU3gLqfHYxA/zIKt0MGO TwwjjI7o+B9K5NzOjP7hV473KAeo2L/qLBWvifQYCrTAc7Cj/XR0GltMueq9Dy+i2VPX +8xbcKZsizEqn4omNQn3nWUsWzrLdvBG0UQwjCmdp52xUfGebEiPuWOF+JxprWFHTZiB sX3dXTlaydtRKOVX3chIGjE+Wweb+4vERPG9JJFVH1wY1o7+emlX1fdUh+DiK3mB7/qo BJJg== X-Gm-Message-State: ACrzQf3Yu/kw2FGoRTXVCFQlhbPXW9W+6uXDhsQs5/vDhkz/LAbrLNJF BQgoLjcKyKlM2CjqAhrP3/l4IGUnRva5MIjm9y8EA5RGwDrA8I+8LTGwfEQZug2mqRvsz7er0Md 305a3yrfQjhU= X-Received: by 2002:a05:6000:86:b0:228:db07:24bc with SMTP id m6-20020a056000008600b00228db0724bcmr1903598wrx.204.1664451266818; Thu, 29 Sep 2022 04:34:26 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4AKzy0m1AK1alKmeZNml2sx8JdsLKH3XBovmokuz24KFW2iqhUvLM4hqCNLY8UmOfW6StkFw== X-Received: by 2002:a05:6000:86:b0:228:db07:24bc with SMTP id m6-20020a056000008600b00228db0724bcmr1903572wrx.204.1664451266401; Thu, 29 Sep 2022 04:34:26 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:ce00:b5d:2b28:1eb5:9245? (p200300cbc705ce000b5d2b281eb59245.dip0.t-ipconnect.de. [2003:cb:c705:ce00:b5d:2b28:1eb5:9245]) by smtp.gmail.com with ESMTPSA id q17-20020adff511000000b002253fd19a6asm8219675wro.18.2022.09.29.04.34.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Sep 2022 04:34:25 -0700 (PDT) Message-ID: <889909f6-f2db-f34a-0305-eb8500dd5453@redhat.com> Date: Thu, 29 Sep 2022 13:34:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH 0/3] ksm: fix incorrect count of merged pages when enabling use_zero_pages To: Claudio Imbrenda , xu.xin.sc@gmail.com Cc: akpm@linux-foundation.org, imbrenda@linux.vnet.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xu xin References: <20220929025206.280970-1-xu.xin16@zte.com.cn> <20220929124242.60ef57ee@p-imbrenda> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220929124242.60ef57ee@p-imbrenda> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XPuGtjI+; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664451272; a=rsa-sha256; cv=none; b=Al9mIsQa5JxBniloScfi/vIIsltoUxm2Au3LtLx3KSCI10QjaFFYZ43zuoJEym84MBVmAn Wi/4Eh1ToXN1hdEJptF3fHC7nIiDNaJ6mUecKm7io28L4wToyqJ0q03B6FsOPsLNzhxYZE ukqsKzR5gfYydbLUSm9GxYKTT8EroZ8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664451272; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xlKGV7zI8yovT8Qjaw1ezWS3Z9lVHmoWfs71GWUdoy4=; b=6yzvkb54OCy4tx0K1LcGuvoICYqLZrc/7cGgtNP62rawR+NU3SPx3WWZTzfEZlHEryjfwl Ov9Dbr1MXxmw4/dzs8TLUqKUafmezZJ+Y+LUUbb5ooPOdqOp82Q9hwYIu/Uv4+e2ZVj5fY xD4mncDx6kIV/IB0lKp0uxpOc2t7FFo= Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XPuGtjI+; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Stat-Signature: i9hfxoh7qrp4tr1b36ddwpqk8ygcoz7s X-Rspamd-Queue-Id: F3A20120003 X-Rspamd-Server: rspam05 X-HE-Tag: 1664451271-171841 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: On 29.09.22 12:42, Claudio Imbrenda wrote: > On Thu, 29 Sep 2022 02:52:06 +0000 > xu.xin.sc@gmail.com wrote: > >> From: xu xin >> >> Before enabling use_zero_pages by setting /sys/kernel/mm/ksm/ >> use_zero_pages to 1, pages_sharing of KSM is basically accurate. But >> after enabling use_zero_pages, all empty pages that are merged with >> kernel zero page are not counted in pages_sharing or pages_shared. > > that's because those pages are not shared between different processes. They are probably the most shared pages between processes in the kernel. They are simply not KSM pages, that's what makes accounting tricky here. > >> That is because the rmap_items of these ksm zero pages are not >> appended to The Stable Tree of KSM. >> >> We need to add the count of empty pages to let users know how many empty >> pages are merged with kernel zero page(s). > > why? > > do you need to know how many untouched zero pages a process has? > > does it make a difference if the zero page is really untouched or if it > was touched in the past but it is now zero? I'd also like to understand the rationale. Is it about estimating memory demands when each and every shared page could get unshared? -- Thanks, David / dhildenb