From patchwork Tue Oct 11 02:20:06 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: xu xin X-Patchwork-Id: 13003557 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 97123C433F5 for ; Tue, 11 Oct 2022 02:20:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EEC76B0072; Mon, 10 Oct 2022 22:20:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89F816B0073; Mon, 10 Oct 2022 22:20:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 765F46B0074; Mon, 10 Oct 2022 22:20:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 635B66B0072 for ; Mon, 10 Oct 2022 22:20:23 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1A0671A0EA8 for ; Tue, 11 Oct 2022 02:20:23 +0000 (UTC) X-FDA: 80007064326.20.2D2DC1A Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by imf08.hostedemail.com (Postfix) with ESMTP id B9A26160023 for ; Tue, 11 Oct 2022 02:20:22 +0000 (UTC) Received: by mail-pl1-f193.google.com with SMTP id x6so11907604pll.11 for ; Mon, 10 Oct 2022 19:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=eW7DNlS16RoYLT6uJ2WK221+Zbzraxz3CxrZYCkWg6s=; b=DClq4d3tRxArm/g8fpYhcSWamPmA1Jukadx3EurAVBGfxfRbUXs/RmyhFWErNs6pMW 5Lm38IISQuDDp5MoY8VbFJ72OC0EULNkeI9mmbGMrSJjAuAS64vYFDc9bnBnbt92GMBH O7G2jVQPS2LzaJlZD3JGZr4pZrAQkNUtXynlUy3hHoUv4D+dbefZpiMQZ5aoM7hDdcgu nx9a6K3oNW4GnJg7oAmlOscNoQ6Jg8pEmEgALYqLIuEpUvkcgF9R7dv7xzrTDSo9HDs5 r1A03KUIC/YFMQ/cHl8c6pQ2LJ35jW8ngd79jB2POGOKwPhZ+UcJMdBuVFeKlUhc2DwU 6zLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eW7DNlS16RoYLT6uJ2WK221+Zbzraxz3CxrZYCkWg6s=; b=qZ8kRlWYBRwIyUcqaSaWJi+CXknLMEmliJ8n3e9muIjBfUVjW6jPZb7GpL7qtTWC2Z ar4ITvHJnCMhY3diAMLYPPKFfSVHa3eaevRpBWbb9X5sUQarVqSomn2jatoY7R39tWBP wWXjli9dCHMGlQ3R9oYBy33NXcvPmiYSu3AXiYMQJ78Nv1xAoCNT5hrYbGSenea6BBfN Z8pXqnJnsRm7t3EJ1TsxhmHsV9L34lUAn0Kwzs+Qbo+LA2//NWzljhlP4MsWnLrhY95/ /UkOjrMQ0ptq8xw8zUxu/t/JbqtZV3pVu5rAtMgBJ3XTrzebK4KOvqYIRDpciyQu3zYB hgmg== X-Gm-Message-State: ACrzQf2D9hZpEbNHkIAJXKbM2/cD8OnEEmxYwL+nucsCeHudek/tan3D dovtFlImaVs+TWuq00wcbMs= X-Google-Smtp-Source: AMsMyM4db7aeAn3whyejbDBpKCgk18j+dGFcSbcbo7dxg9AmV24f3yLdmA1e41g7X7HL5ofBeMQN5w== X-Received: by 2002:a17:902:b945:b0:181:c6b6:abc with SMTP id h5-20020a170902b94500b00181c6b60abcmr11342027pls.75.1665454821504; Mon, 10 Oct 2022 19:20:21 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id k17-20020a170902c41100b0017f8094a52asm7471998plk.29.2022.10.10.19.20.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Oct 2022 19:20:20 -0700 (PDT) From: xu.xin.sc@gmail.com X-Google-Original-From: xu.xin16@zte.com.cn To: akpm@linux-foundation.org Cc: ran.xiaokai@zte.com.cn, yang.yang29@zte.com.cn, jiang.xuexin@zte.com.cn, imbrenda@linux.ibm.com, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xu xin Subject: [PATCH v3 0/5] ksm: support tracking KSM-placed zero-pages Date: Tue, 11 Oct 2022 02:20:06 +0000 Message-Id: <20221011022006.322158-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665454822; 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:references:dkim-signature; bh=eW7DNlS16RoYLT6uJ2WK221+Zbzraxz3CxrZYCkWg6s=; b=Sx/X395SX7sKrYwriOK2J9SiWGtLIPnO7TXPOvIxqdZePcDYseCusS9sLXOUT4zlMtkBzz DeDsKDHFYzdLamL2hS26CbtSot3mEvPfPkUxmOtqn3JUqB1eq+8x71ZsvOaJpPcd+xDKNA abe4I13mpSMK0GrAhNtJalF6plKMGLw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=DClq4d3t; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.214.193 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665454822; a=rsa-sha256; cv=none; b=GlhIzZk6btS6H8Iv7a0RkcNI6ZxU6IeJ6V05Qfpn780jIp8p9o5nqOYrZKihkyfIyZEI8e +m/d3ZcgOrjOfcPJe5wFe05G8m/u30HHwa6AaX/cIxP1GC+nTljy5tpPk/Eg7oYxCz6n1J JHr0lKrvE9qPxoggGE067VCdE3ab1uc= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=DClq4d3t; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.214.193 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com X-Stat-Signature: 8zbeiyiw7qooojk3mic77yt45q59rrdc X-Rspamd-Queue-Id: B9A26160023 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1665454822-798634 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: 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: 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/ 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. Zero pages may be the most common merged pages in actual environment(not only VM but also including other application like containers). Enabling use_zero_pages in the environment with plenty of empty pages(full of zeros) will be very useful. Users and app developer can also benefit from knowing the proportion of zero pages in all merged pages to optimize applications. With the patch series, we can both unshare zero-pages(KSM-placed) accurately and count ksm zero pages with enabling use_zero_pages. --- v2->v3: 1) Add more descriptive information in cover letter. 2) In [patch 2/5], add more commit log for explaining reasons. 3) In [patch 2/5], fix misuse of break_ksm() in unmerge_ksm_pages(): break_ksm(vma, addr, NULL) -> break_ksm(vma, addr, false); --- v1->v2: [patch 4/5] fix build warning, mm/ksm.c:550, misleading indentation; statement 'rmap_item->mm->ksm_zero_pages_sharing--;' is not part of the previous 'if'. *** BLURB HERE *** xu xin (5): ksm: abstract the function try_to_get_old_rmap_item ksm: support unsharing zero pages placed by KSM ksm: count all zero pages placed by KSM ksm: count zero pages for each process ksm: add zero_pages_sharing documentation Documentation/admin-guide/mm/ksm.rst | 10 +- fs/proc/base.c | 1 + include/linux/mm_types.h | 7 +- mm/ksm.c | 177 +++++++++++++++++++++------ 4 files changed, 157 insertions(+), 38 deletions(-)