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 21368C433FE for ; Mon, 10 Oct 2022 12:08:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7207F6B0071; Mon, 10 Oct 2022 08:08:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CF24900002; Mon, 10 Oct 2022 08:08:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 570786B0074; Mon, 10 Oct 2022 08:08:44 -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 411CF6B0071 for ; Mon, 10 Oct 2022 08:08:44 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1801A80A25 for ; Mon, 10 Oct 2022 12:08:44 +0000 (UTC) X-FDA: 80004918168.28.DCE7862 Received: from mail-pj1-f65.google.com (mail-pj1-f65.google.com [209.85.216.65]) by imf18.hostedemail.com (Postfix) with ESMTP id B91C11C0028 for ; Mon, 10 Oct 2022 12:08:43 +0000 (UTC) Received: by mail-pj1-f65.google.com with SMTP id d7-20020a17090a2a4700b0020d268b1f02so3495619pjg.1 for ; Mon, 10 Oct 2022 05:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=FwPMwCgbi/FbAd9r1+fUWWjocTEXzlErLf/J4KoA6Pw=; b=D3fg/uc7O/MeJ7dpIE5CVLx02YbILU+5RamhHoy2B6Q2HH0R0s4CgnZXprAsun6ROi /VdDCXReoNG6k7t5xllDH9bqMHmXIDDWhpRG5/4BQfk45l4yhlUSjUMP09fbcnTa1tXI /SNzpnHpGcxgqaNws4pgacDVBDmUPtlNci0Mw//ZvMRz5gEoDe6x4Fiqf47opl3hLpvD bXUUywZ+kJZjS4afh9HE2HSx1TCRAFuBdPduKLXdaA0pACBHvYh/WjWmYsMLJPhBmfY7 oQ0qef9HRNuBo/EEgaYcs2jVYeKquu7PO1zz4AU0rrbpowBAaGQfG8tKnrQ5FO8YJjLV aIYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FwPMwCgbi/FbAd9r1+fUWWjocTEXzlErLf/J4KoA6Pw=; b=BN8rK0E0/ZJPlcu5QnKl9IWKxE8NF3OIYBnh8qESeIrSEIIT0N9Gg58fn2NQvMgH/n FKFJkyu70k/9Z8dMoBoCpeD/efZl5SqSSjyK1JR8xGXhPCp1upc0rk8CmkwUCl3d0Ddu lFDXG9ZD4nGhmG1wD4EomlW4ZisP+0yY0ee/jpiLkLkQ/efRn3hK2RdrVRQZ1meBZOIY vUCXO+gtqU3z4cqYKDDqE+M2lTpxiVtfZe8yNgjv2YOeurUtIvI6ITOnwDUw96QL+3UU eYbyuP458XXKNMPFkph/zReazJyK+xqtfRZEI4RhptbgSIDYHGLp4odVLZiih21R1Ol8 +Igw== X-Gm-Message-State: ACrzQf330JCzcuOpK9E33vGrsct6gRgoJnn18sxWBXnWIxlAj/MlBZ8I JtXsQT9xSkLVcAVtIipzIlM= X-Google-Smtp-Source: AMsMyM4vLi3GcSqeCddr3ROeQF4vbYLLY8389qsb0JZqfTBvEc8m0hNlQIYxla2uh+gtchudzHZ84Q== X-Received: by 2002:a17:902:f650:b0:172:8ee1:7f40 with SMTP id m16-20020a170902f65000b001728ee17f40mr19161423plg.101.1665403722671; Mon, 10 Oct 2022 05:08:42 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id h11-20020a17090a130b00b00208c58d5a0esm9037177pja.40.2022.10.10.05.08.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Oct 2022 05:08:41 -0700 (PDT) From: xu xin X-Google-Original-From: xu xin To: imbrenda@linux.ibm.com Cc: akpm@linux-foundation.org, david@redhat.com, jiang.xuexin@zte.com.cn, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ran.xiaokai@zte.com.cn, xu.xin.sc@gmail.com, xu.xin16@zte.com.cn, yang.yang29@zte.com.cn Subject: Re: [PATCH v2 0/5] ksm: support tracking KSM-placed zero-pages Date: Mon, 10 Oct 2022 12:08:34 +0000 Message-Id: <20221010120834.318840-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221010112413.219dc989@p-imbrenda> References: <20221010112413.219dc989@p-imbrenda> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665403723; a=rsa-sha256; cv=none; b=VvOtvFUGGUGjGj0oA+cdY3gSoQrqLUHxh2BIBQWlhOc+kmMX2z+icHxCJMeP5ESRu9e5a7 gZBI2L73amgf+AHfVNqyYljennn7U9XruN5KYW8tFz7ekK8Qb/gB1/DJvAoTwQEAPDedtP n9TCXQ1nnTIyWVF/miSY4VuFbZn8mW0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="D3fg/uc7"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.216.65 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665403723; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FwPMwCgbi/FbAd9r1+fUWWjocTEXzlErLf/J4KoA6Pw=; b=YROv5/Lk96SgxD0wsu3IHdnXLJ/mPiYZmauIZKJOu6RXfKHy1UJHMMNH08sO6dUPmaCjPq 6ru+LDJytXZcy3a+580pqroiHr+2TlHp5VgNPcrdBzZikjTedIONM89UHMO4DnKghlTjS4 YgP14G2RaVVcRlUrmt+l71TS6DmHH68= X-Stat-Signature: rqo74m5c73asi776hcwckuii4p4boxjq X-Rspamd-Queue-Id: B91C11C0028 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="D3fg/uc7"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.216.65 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1665403723-575913 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000190, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, Thanks for your reply. > >why are you trying so hard to fix something that is not broken? Actually, it breaks the definition of unmerge, though it's usually not a big problem. > >can't you just avoid using use_zero_pages? use_zero_pages is good, not just because of cache colouring as described in doc, but also because use_zero_pages can accelerate merging empty pages when there are plenty of empty pages (full of zeros) as the time of page-by-page comparision (unstable_tree_search_insert) is saved. > >why is it so important to know how many zero pages have been merged? >and why do you want to unmerge them? Zero pages may be the most common merged pages in actual environment(not only VM but also including other application like containers). Sometimes customers (app developers) are very interested in how many non-zero-pages are actually merged in their apps. > >the important thing is that the sysadmin knows how much memory would be >needed to do the unmerge, and that information is already there. > I think it's about chicken-and-egg problem. Anyway, thanks for your reply.