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 B0A9CC76196 for ; Mon, 3 Apr 2023 15:20:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3811F900002; Mon, 3 Apr 2023 11:20:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 309746B0078; Mon, 3 Apr 2023 11:20:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18365900002; Mon, 3 Apr 2023 11:20:31 -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 036DF6B0075 for ; Mon, 3 Apr 2023 11:20:31 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AF77AC0AD0 for ; Mon, 3 Apr 2023 15:20:30 +0000 (UTC) X-FDA: 80640441420.24.F01B709 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id B7A53C0019 for ; Mon, 3 Apr 2023 15:20:27 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BlG3+3tu; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680535228; 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=MUeaj7hBfuCp2NtQjNloBx3xDvLT9LLe4pBcw9XRijI=; b=rtXV1GpcUN82YFTeqFu4W9ZvR0pTH0fQZl+93uFokvnfRytSP9mKEdpUeOFlxmCXs791aJ UboJRR3oSLohu4uFN13CtXssimVS4KUPll1g760Sxnu38ZRkGG+bwy9rPBBQ0ldwhwgJIZ ZtDwHg8e27v7UoBf0UF39/YdNiDAbgE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BlG3+3tu; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.133.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=1680535228; a=rsa-sha256; cv=none; b=vK94jgL5JMYyeSH0pVRUIeRFuBa0M2cnFSh4KpokkIGKBJ5fwtZUP//8R2dBsH/VfnPwRT eHpzuJruR0o/aWjsRvDyg6JkAkk/prYE/J7gpgc6BIVrPTJpdN/PBBOuiZhz5l7JdSJNS6 +lW9CPZ10Hb9bx2snYa4PTKzdOO+UsQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680535227; 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=MUeaj7hBfuCp2NtQjNloBx3xDvLT9LLe4pBcw9XRijI=; b=BlG3+3tuZfk5Dy+JqrDeRUiOaQ9CfggLu79mTWxBgq/9Waxdhx8e/Pn6lvLIvOv5T06ANm R8m3fBo7OJA3Q0WZjkf7Gd5guwVpIrneMpSygx/7jVhsft9LVBIxMDEFV5GCjQfeD4SS+s Ucep91wYKliOJOPkczxC23DpiXSEAj8= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-226-hMM-D2edOSeD8rvK1cI92g-1; Mon, 03 Apr 2023 11:20:25 -0400 X-MC-Unique: hMM-D2edOSeD8rvK1cI92g-1 Received: by mail-wm1-f71.google.com with SMTP id o37-20020a05600c512500b003edd119ec9eso14735617wms.0 for ; Mon, 03 Apr 2023 08:20:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680535224; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MUeaj7hBfuCp2NtQjNloBx3xDvLT9LLe4pBcw9XRijI=; b=aNdIki4OLoCtvVlv0CIIEwWLUECTT01zmGLLGwWv9RtxNoeNgdEmun5HwF8YWDXgc/ kgN4oUkVAg+iSirwlKiaSy07p4A4gqd6ngJF7/vMsyywqVsr0xgklIue3YC4yW4H2zuH q+bOmDmq0yZWdsi1ijDXzgvm705bJdNW4x/2ArjsEmRVQGVaezjHVy573qdhRvnD+YGG fv658/iIbci0Xi3/3WIQ066GdasYaP0aHvA9V1ep1QMSDxieZ8SbBFJU7k7tlDAlEJix NESOx/q4IYdPmVy2SZmoBBaqNbPFiAJOQmKxS7ESiMZ2ghxdWapimkwPYV8UOmfvvgxH uAXg== X-Gm-Message-State: AAQBX9c4PXd/3/nm+y2PrDF7zFeSvsDJv+1AHvZ7GLvPsz3dkFKS7y3V kqSfBS1pZ643rTLWH3duDHKpZMwO7mpas6r791I9049mB868PFxnXIqpTCtkaMHYdflXG897+cS PJ/c8tvHMVZI= X-Received: by 2002:a5d:650d:0:b0:2e4:bfa0:8c2f with SMTP id x13-20020a5d650d000000b002e4bfa08c2fmr11440335wru.47.1680535224626; Mon, 03 Apr 2023 08:20:24 -0700 (PDT) X-Google-Smtp-Source: AKy350a6wVwzOx9EXdz0NZZ4oD+60oiKSpdfYDgkoEKg8O54qtXyUeqlh0i0Ix+QB0cWJVAUVQo99g== X-Received: by 2002:a5d:650d:0:b0:2e4:bfa0:8c2f with SMTP id x13-20020a5d650d000000b002e4bfa08c2fmr11440314wru.47.1680535224277; Mon, 03 Apr 2023 08:20:24 -0700 (PDT) Received: from ?IPV6:2003:cb:c702:5e00:8e78:71f3:6243:77f0? (p200300cbc7025e008e7871f3624377f0.dip0.t-ipconnect.de. [2003:cb:c702:5e00:8e78:71f3:6243:77f0]) by smtp.gmail.com with ESMTPSA id j7-20020a5d6047000000b002e105c017adsm9973759wrt.44.2023.04.03.08.20.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Apr 2023 08:20:23 -0700 (PDT) Message-ID: <533a7c3d-3a48-b16b-b421-6e8386e0b142@redhat.com> Date: Mon, 3 Apr 2023 17:20:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 To: xu xin Cc: akpm@linux-foundation.org, imbrenda@linux.ibm.com, jiang.xuexin@zte.com.cn, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ran.xiaokai@zte.com.cn, xu.xin16@zte.com.cn, yang.yang29@zte.com.cn References: <78e35d88-8a4e-3b36-bbbd-94048c0c5b54@redhat.com> <20230330120654.120937-1-xu.xin16@zte.com.cn> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v6 0/6] ksm: support tracking KSM-placed zero-pages In-Reply-To: <20230330120654.120937-1-xu.xin16@zte.com.cn> 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 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 64mz68ioig96i7nmkkhgokasx8mb4g8t X-Rspamd-Queue-Id: B7A53C0019 X-HE-Tag: 1680535227-172385 X-HE-Meta: U2FsdGVkX1+mYG/gNsdcT4k0ru4PtGnTsPvFdnGvuLZl4Hu3Hhsgo/Pw+KgOKEJI1dj0/gmAEq3cxFIGGyQiQfo9ZX9cKyhfESturJY3mIg5D9EyZdHmfzOMJw6qZwchcXZtsk0tuGSZX9+BBOKFvjpy6tIup1SkZ1Vdm/uPmxsob2PYu/r0IJwggLvkog1rTidyqCyPjcaF4mG35uK7DRvCDZOP/hzOXlixZacWMOUeDL0dajgHHm9ODgcwzwgz6kgrUMNB5gtO6qqYIGxsuRkdJ3LjrHNu9iG1R4P/VmnimCj/H1wSlsg/i6Lw0ArKWQ9cuPe1ZSSASQSK+Sd8eaDsRZ0pSfQNdWKP0GgiNNdd1wWuzTfVs70FTrHkNwktmXzzQWHc1KI5hDQJ/1r9nAirfcJbwa2s0F4XEb+tLoFEDFPJD2JiyNfov2zn5kg2v6y4ylgmoedl15daJBOgtcGMKexeG56rPZLGxtDlDRQnS2mhGoH/buZ87UtZIgY/Ii+Scn4lWMb/hxtcSkfFwBDAEwonxKMpgZaZ0LKGKi85ouNGqWsnoz0kes9xRr375Nh4o9rInUx5rQ61BAglXGg1BpiywEyY3liHVBWs8odKxohG04wocAvj0wi15ZFfgvZIsVVQad6vgvIxrgJdEgYsNN90KC3H3kAwVxVgvPRU9suvyf6epKgYVtmKKustclWWWa5UrAvGSNHfFM+Ta4UYlwQa7Je+HKtKhFNDl3Hi1wifkruwyLDSk+xDop9JexPzPENGAZ6YrIdjIyY1grRjWVZE7n3okjruwXka7Ls+sv3BnhUyvDdVcekUuK0bmFfitptYsNXUGbXLtOLXlnDTDtAvvck2TOlWIzDw5RgFFwGXKwRcGAiohv+9e1CrQzh5i0wi4QadwzglgujXYkB2xLvn7ixU8XqJo7VpsgEUBZI40TEtgHTP2c+gPSs4RX0XwPd2am4O0gtdMgD OKUdH10z GviqF2s3gXUnruL6gCZlHFc5sDe19gJX1ZrIvFW8u2KmAqqjdSvnmLobFO1tzNx4BFy95N/2ysLGJFYsvygyJ0TgdMIlIAYqV6XBzxWA3q2oY98XMP9T1agUt1kR7TT0FVCXNdskkv0pqHOb2cjdmnLysWxVv2SV0/sJLVOP5b8xOMW6JSg9yq0EO2BCOr5PBfvs2D66G4bXzysGGWg+uOIVBrpuRowdVRSsBDkkjCmKnJCZTibk3WX32mfDPzCjWqNSl7De8tNqLW6phqYe2Fizqkr7jLawFsnUH91yhQOTXi+ChhapwZpBRZ2TF2I7tL/CjClebxN5Br2zmdqWolXrq9oMsE2ExX36vlMCt7EviQRjYugOQVssmoL+58CbFGLKtT96w0sKmkWlfIFLwo1TZoHiOIY4E5ft9gEXpVB5mn0fZusaOR8xcfGxnyMrcDWiraSTXON/2YsORwCqeDLaUEuvu3HTiQNBNVqiXDF5DUZ4vbrxVZr1uIz2feewMVdockgoJqE8mvpMJVWzh1WzC4ZsRYYKUTyek11RQfTq1jmrcI6k7V/TWesc2GSBzinOwghkzyNb1ULY= 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 30.03.23 14:06, xu xin wrote: > Hi, I'm sorry to reply so late because I was so busy with my job matters recently. > > I appreciate David's idea of simplifying the implement of tracking KSM-placed zero pages. > But I'm confused with how to implement that via pte_mkdirty/pte_dirty without affecting > other functions now and in the future. No need to worry about too much about the future here :) > >> >> I already shared some feedback in [1]. I think we should try to simplify >> this handling, as proposed in that mail. Still waiting for a reply. >> >> [1] >> https://lore.kernel.org/all/9d7a8be3-ee9e-3492-841b-a0af9952ef36@redhat.com/ > > I have some questions about using pte_mkdirty to mark KSM-placed zero pages. > > (1) Will KSM using pte_mkdirty to mark KSM-placed zero pages collides with the existing > handling of the same pte in other featutes? And in the future, what if there are new > codes also using pte_mkdirty for other goals. So far I am not aware of other users of the dirty bit for the shared zeropage. If ever required (why?) we could try finding another PTE bit. Or use a completely separate set of zeropages, if ever really running out of PTE bits. I selected pte_dirty() because it's available on all architectures and should be unused on the shared zeropage (always clean). Until then, we only have to worry about architectures that treat R/O dirty PTEs as writable (I only know sparc64), maybe a good justification to finally fix sparc64 and identify others. Again, happy to help here. [1] > > (2) Can the literal meaning of pte_mkdiry represents a pte that points to ksm zero page? I briefly scanned the code. pte_dirty() should mostly not matter for the shared zeropage. We have to double check (will do as well). > > (3) Suppose we use the pte_mkdirty approach, how to update/decline the count of ksm_zero_pages > when upper app writting on the page triggers COW(Copy on Write)? In *mm_fault outside > mm/ksm.c ? yes. Do it synchronously when unmapping the shared zeropage. diff --git a/mm/memory.c b/mm/memory.c index f456f3b5049c..78b6c60602dd 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1351,6 +1351,8 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma, pte_install_uffd_wp_if_needed(vma, addr, pte, pteval); } +#define is_ksm_zero_pte(pte) (is_zero_pfn(pte_pfn(pte)) && pte_dirty(pte)) + static unsigned long zap_pte_range(struct mmu_gather *tlb, struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, unsigned long end, @@ -1392,8 +1394,11 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb, tlb_remove_tlb_entry(tlb, pte, addr); zap_install_uffd_wp_if_needed(vma, addr, pte, details, ptent); - if (unlikely(!page)) + if (unlikely(!page)) { + if (is_ksm_zero_pte(ptent)) + /* TODO: adjust counter */ continue; + } delay_rmap = 0; if (!PageAnon(page)) { @@ -3111,6 +3116,8 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf) inc_mm_counter(mm, MM_ANONPAGES); } } else { + if (is_ksm_zero_pte(orig_pte)) + /* TODO: adjust counter */ inc_mm_counter(mm, MM_ANONPAGES); } flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte)); The nice thing is, if we get it wrong we "only" get wrong counters. A prototype for that should be fairly simple -- to see what we're missing. > > > Move the previos message here to reply together. >> The problem with this approach I see is that it fundamentally relies on >> the rmap/stable-tree to detect whether a zeropage was placed or not. >> >> I was wondering, why we even need an rmap item *at all* anymore. Why >> can't we place the shared zeropage an call it a day (remove the rmap >> item)? Once we placed a shared zeropage, the next KSM scan should better >> just ignore it, it's already deduplicated. > > The reason is as follows ... > Initially, all scanned pages by ksmd will be assigned a rmap_item storing the page > information and ksm information, which helps ksmd can know every scanned pages' status and > update all counts especialy when COW happens. But since use_zero_pages feature was merged, > the situation changed, ksm zero pages is the only exception of ksm-scanned page without owning > a rmap_item in KSM, which leads to ksmd even don't know the existing of KSM-placed, and thus > causes the problem of our patches aimed to solve. > Understood, so per-PTE information would similarly work. [1] https://lkml.kernel.org/r/20221212130213.136267-1-david@redhat.com -- Thanks, David / dhildenb