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 D131FC433FE for ; Tue, 18 Oct 2022 09:00:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C7C36B0072; Tue, 18 Oct 2022 05:00:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6782A6B0075; Tue, 18 Oct 2022 05:00:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5666C6B0078; Tue, 18 Oct 2022 05:00:39 -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 474AD6B0072 for ; Tue, 18 Oct 2022 05:00:39 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C3A6E160FDB for ; Tue, 18 Oct 2022 09:00:38 +0000 (UTC) X-FDA: 80033474556.14.C1B9A4D Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf01.hostedemail.com (Postfix) with ESMTP id 599E44004A for ; Tue, 18 Oct 2022 09:00:38 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id p127so14222773oih.9 for ; Tue, 18 Oct 2022 02:00:38 -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=q+56dTD/8cT5IfVvyasJwmIdp2twkCvx6msURbR8+es=; b=BJ5Mtg77vy2RCI/I0S5/pUvavbtY9TQevILRWPDF4d+wtdZ0dtySFq/is7++FzUOTj SKUt5C94T/JF0MFD/oU1c45bI5KWHsVGznA6pm/iaKR+/uSdvdF+U/yfAyePgg4EC18u 3Aj5EcEoTM69VGRSBxhgKXRzzOHAFKH9zxKXI2kW6IkZcQaAiE1yxHiMj6RkSc+HLxjO 4SCB9uIjktgxe+UFa75Ovuy3h9wImF78VNVDmM8rF54NJfZm/8l2pQ1Aon04A6Rq//fW 59SmTUCCnxS/j4FZMvKnfKl5Eetqeo/90HwQgvZKe8cW/+zukT7bVrg6BjmNjp4IyhBf xhuA== 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=q+56dTD/8cT5IfVvyasJwmIdp2twkCvx6msURbR8+es=; b=n9EDsZHDDmT+THyJ8dQMzoUdkDjU/dPjvY4cV4A5+3No/2ULQbfTAPIxHTKVHF0MPj mxe/+3gjGj7S9QzcQXKpcBv12E/V2S+w3uzbY+LUVAu+fY/1uI6hqFR23z0kuljJfNSw c8tdUj1Iw2PjzJ1H+KLv+3zxtvFaBuuuwz6I+gk1E5yR5OJlf8qUZ1tEAQCk0ceD/GvF yAD6NTjhHFGxcL4T4HULUdsl53cZpbkrE3VaZ6R+JyWKfVVDqvORYIh33khM2Qv9uSVQ vc0KspXu9JdidHzHOIOi2NrYAkNeIXyGuE8BFyxPhoEHlP5LW5pJ9xsXQC8QNScv4qWi WdWA== X-Gm-Message-State: ACrzQf2V6uBGimdk/8q8JB2S5TFbQrj81ihLE9bCeJ2+HLtFx7oxtiS/ 0fzQyKkopZ4mhZp05f5t8WfNysSjOQs= X-Google-Smtp-Source: AMsMyM5nTFXOHtUrp/JRn7GesABoGAzRksLmNUAKPo7RyGZNVfYZ7SOpD4Ts2KhzHMbwHolUvuGm2A== X-Received: by 2002:a17:90b:390c:b0:20d:a662:dac2 with SMTP id ob12-20020a17090b390c00b0020da662dac2mr30666114pjb.5.1666083627341; Tue, 18 Oct 2022 02:00:27 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id k18-20020a170902c41200b0017b224969d6sm8258480plk.76.2022.10.18.02.00.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 02:00:26 -0700 (PDT) From: xu xin X-Google-Original-From: xu xin To: akpm@linux-foundation.org Cc: david@redhat.com, imbrenda@linux.ibm.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 v3 0/5] ksm: support tracking KSM-placed zero-pages Date: Tue, 18 Oct 2022 09:00:22 +0000 Message-Id: <20221018090022.373574-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221017165541.6e2d3cebdc1ba13861ea4b2b@linux-foundation.org> References: <20221017165541.6e2d3cebdc1ba13861ea4b2b@linux-foundation.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666083638; a=rsa-sha256; cv=none; b=8XsxRXMu/bPko/cYcojKPDO7YmnrmrqTwtxZT/ugiSE/8jQS1vGyAIhh78w53CtZGskO8X wEsFEsG99sc7G5xRuyOHRhPsDaW04N7SZx5FIIz9jFzPcdF0/YtGBswQnriqXwtpFUqWTp N33jS/Fa7OnozD5+jcbef2hd3pO82yI= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BJ5Mtg77; spf=pass (imf01.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.167.193 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666083638; 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=q+56dTD/8cT5IfVvyasJwmIdp2twkCvx6msURbR8+es=; b=rahh+aciTvw+6t+JjS8eOIor+y5IUBHho5C1q1zbI0SttB3JcbWILxY8uoGjguk3NqjDpF xiPYLrfPTAoMJ9fzZqw0T8d/otQNxfk3vLdDQj03VlHVtHDPq1DCTAw3/1yeD8xIbk7r4k 8sZna2+9kKB48M422PrZj/7fZGG03KY= X-Stat-Signature: gm5yach5babf1jq6c5kddsfbhpzr71xp X-Rspamd-Queue-Id: 599E44004A X-Rspam-User: X-Rspamd-Server: rspam03 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BJ5Mtg77; spf=pass (imf01.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.167.193 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1666083638-928928 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000238, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: >> From: xu xin >> >> 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 comparisons (unstable_tree_search_insert) is saved. >> >> But there is something to improve, that is, when enabling use_zero_pages, >> all empty pages will be merged with kernel zero pages instead of with each >> other as use_zero_pages is disabled, and then these zero-pages are no longer >> managed and monitor by KSM, which leads to two issues at least: > >Sorry, but I'm struggling to understand what real value this patchset >offers. > >> 1) MADV_UNMERGEABLE and other ways to trigger unsharing will *not* >> unshare the shared zeropage as placed by KSM (which is against the >> MADV_UNMERGEABLE documentation at least); see the link: >> https://lore.kernel.org/lkml/4a3daba6-18f9-d252-697c-197f65578c44@redhat.com/ > >Is that causing users any real-world problem? If not, just change the >documentation? > >> 2) we cannot know how many pages are zero pages placed by KSM when >> enabling use_zero_pages, which leads to KSM not being transparent >> with all actual merged pages by KSM. > >Why is this a problem? > >A full description of the real-world end-user operational benefits of >these changes would help, please. > The core idea of this patch set is to enable users to perceive the number of any pages merged by KSM, regardless of whether use_zero_page switch has been turned on, so that users can know how much free memory increase is really due to their madvise(MERGEABLE) actions. The motivation for me to do this is that when I do an application optimization of KSM on embedded Linux for 5G platform, I find that ksm_merging_pages of some process becomes very small(but used to be large), which led me to think that there was any problem with the application KSM-madvise strategy, but in fact, it was only because use_zero_pages is on.