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 13CB5C25B76 for ; Wed, 5 Jun 2024 09:49:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9711D6B009D; Wed, 5 Jun 2024 05:49:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91FF36B009E; Wed, 5 Jun 2024 05:49:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C0456B009F; Wed, 5 Jun 2024 05:49:16 -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 5D9AC6B009D for ; Wed, 5 Jun 2024 05:49:16 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1A97F140D23 for ; Wed, 5 Jun 2024 09:49:16 +0000 (UTC) X-FDA: 82196361912.28.749014F Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) by imf15.hostedemail.com (Postfix) with ESMTP id 3DAE4A0004 for ; Wed, 5 Jun 2024 09:49:14 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rxm7gJPy; spf=pass (imf15.hostedemail.com: domain of seakeel@gmail.com designates 209.85.161.48 as permitted sender) smtp.mailfrom=seakeel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717580954; a=rsa-sha256; cv=none; b=2Ca4hd+7i9E+B0RAvPpvG0IRH0R1wwwkZqRhqcR0tpd7upEEfC1J3qe7IGeADgkDgmb4g+ 8MBG7gblhdFS3cdGvcrJebaSQkoje0dQNZ4hCjJOBqB+m7bmN6VwDKc9L21iTjsTrpo02d GNOITF+BH+kSIG9Hw1Kx3TNUSqa9fl8= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rxm7gJPy; spf=pass (imf15.hostedemail.com: domain of seakeel@gmail.com designates 209.85.161.48 as permitted sender) smtp.mailfrom=seakeel@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=1717580954; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=gBpE7UiCHuApO7sKV5bJ6IlGQVWs8dFL+WzC3J5powo=; b=zP8IrixyE6j43S9Hez7h120NEkbuACBwpL2+ybTpjPr+dLWRH+11k//sxyeQUlg8EPiU63 fSD7UAMfgUyy0KLqbbmlJtOMFaO58gMeRtJ7B5KpzuiuwGaxL9GNjh8jUlx2WSM60G84mb gWKkXUwalBrMjqrJYecoxNvbni3rUjE= Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-5b97a071c92so3080261eaf.1 for ; Wed, 05 Jun 2024 02:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717580953; x=1718185753; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=gBpE7UiCHuApO7sKV5bJ6IlGQVWs8dFL+WzC3J5powo=; b=Rxm7gJPy5MEE/yxPg4zWSTi3Sv3iP9aalQAQZZxPH1vunvdXQ87cRHm7KwvJ1MiLCG DXqY2xwXSL4uXPfzd8ilTJgyidoKCdmOjn6aLMnzfP77lIVQ8mLkR/vO2Z736f9VdJ5L wYtQhautWPAqO/dU7aHWgvQC6Ycy68ueybYbjJYnegRR+3F2A7+A8eujawjRQfzldHA9 KZeT5T5Q/hHOVG5EooH6VDVX9qwAMghhQVMdtlFWL/UrASEcoxrm2CMrxIgfkdi/z3WP hbhOEzeH6lI7kstrWlBg2sfBIlPyp2LHYEVg+gqj24FT4HiCnUOKTHYf2ZyAKJh/stgf T1hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717580953; x=1718185753; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gBpE7UiCHuApO7sKV5bJ6IlGQVWs8dFL+WzC3J5powo=; b=euhnFFnROWWFzdORhOOLfNIHWanYguJqVU/WY0s1N4g4EWJyadfZT2W9guwKVtTnya PUxF22jtVDwPtFhHc0vBDJc7PLi0peZB828PSKF7BTHWBeCwLW5jczgyYHL0IVhpN9KO ReGu2ETg8JGl4ceZY7w9mmqWp9VOcOsofuGnvcNgq9jHWLXLvcFXei9g/3O3BuveCS5m kqUymxFTLm/Hwy+G4p7cIi0CqbFe0Lurg5kI5OVgp2AuGzjk7Fb4i9ITeiV8uwKgOIkY YZhojdJ+eQMS/Wm+gz6t9hePmfLvydWgOQyqSx/ZYhdKBuuwxAM1mlK5WZmH5Yu7k2Wi t5YQ== X-Forwarded-Encrypted: i=1; AJvYcCVHhRn5cMjbeO8Xy74UT24G6oM+1lC8cUMkOGeNCeaJ+DR177+V7Ipm9bn6BEfKx11h/8vDyzRHKMzgpmWI99nMQG8= X-Gm-Message-State: AOJu0YxoicHevItygRWU3fZEkXGllB/O2EPj+2N27FSCwL6o+e/Cn+jc GotL78h7/Jp4Hc7F5Zo8L5HaXqSddpcuMJFVb8zs06D0gOepYnzq X-Google-Smtp-Source: AGHT+IEcOXkFEFOaMDaacHQ5vyKJ033GOf8ZPTGEtTmQcafQv5JFPfsnd6BIPsj17eC1ydBaMu4tbQ== X-Received: by 2002:a05:6358:7e45:b0:196:ecaf:a54e with SMTP id e5c5f4694b2df-19c6ca12483mr217805455d.29.1717580952997; Wed, 05 Jun 2024 02:49:12 -0700 (PDT) Received: from [192.168.255.10] ([43.132.141.20]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-6c35a4b973csm7000813a12.79.2024.06.05.02.49.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jun 2024 02:49:12 -0700 (PDT) Message-ID: <1a4f8984-e262-4611-81ec-6ea12fa5b20d@gmail.com> Date: Wed, 5 Jun 2024 17:49:08 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/10] mm/ksm: reduce the flush action for ksm merging page To: David Hildenbrand , alexs@kernel.org, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, izik.eidus@ravellosystems.com, willy@infradead.org, aarcange@redhat.com, chrisw@sous-sol.org, hughd@google.com References: <20240604042454.2012091-1-alexs@kernel.org> <20240604042454.2012091-2-alexs@kernel.org> <9ca730ce-2b2f-42d2-8c7a-78735a995c64@redhat.com> <4d299245-3166-4810-b22b-2a5b4f54a049@gmail.com> <7c6ae2a3-8ec3-4c9b-81c3-125f6973f0f3@redhat.com> <59921e08-d0f1-4bc8-acee-368a978286a4@redhat.com> <41130a02-80cc-4ee4-89ab-e889844a35f7@redhat.com> Content-Language: en-US From: Alex Shi In-Reply-To: <41130a02-80cc-4ee4-89ab-e889844a35f7@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3DAE4A0004 X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: hsuomppcjn55ybpq8amh1g9szw5cefy4 X-HE-Tag: 1717580954-630581 X-HE-Meta: U2FsdGVkX1/yvBy7n45UWrKGD3bpqp7r+/XBHqxcEhb2ATcRTxvbTxWIAMVl7VgODN1u2Y0OxumTSRS9aG5Sc3MAJG/Q2PgfIlHckKIGDlOK25d0RtXUQQcIK2LRAgMlKL9yaczMmhcQ8Fv870Ch55SI7mDs//MI8V5tpt3IDIGqEBjaYp+VR0J9YJOTbhBxcDiRQ9d4ofzVil0qz2KNFuyOVAwQJ/UVPATzlBgIXlcofiYhXMOnss/rDmh3O6oBXN1tf+0ptuy0JNBm+GWqGpVejUr2AIVi2yAjEU4aXnUqTJBLPERpDUz2JgBTmgLD/fndbgM9gHX+TvBroQkqTBYLpftEgR2acMsIJBgGKuyvdbrCnkA6+64cNG1R0vhpKKti1huZJtLvfd5cg0Y+NgvTV/4kgwLY3wfxnuyex+N0aTflDu+MPa40hJzYWlk/JMSstxzpXUfGkP8eWgY4Ipbk2n77o5OhDGe6irShk1wdTh5IS6MeOu5p1DFCjznFJpBUoyPoP5NAw8kUXCsmTFo4r8Z0FicAtwzAeRzfXc1n7ezmKEyg/HXmIIhWB0gAij9eoJbvhwPMGj//zUu1cL/F7IbQeA2RacumXJj7ih4WeMG6MxbHGBsl15UXzy461zcJpwoKMi7RUWzWevNMxmlBJeIeZCGNjJJmtiSgtGB4V8On0qKzJvrBPFQHuxiAZ5NiVqPDZuWEbzEPcTtCuV1SZg8mCDZ1YtkFxcst7s6cgjg6DB+NQ1nocFPgqErLBMpa7hucGF2XHhzy+dLKYzfEwkjEUaH0Y87OuAp9Q51sGoK+rhzLENQU3XGblb7RQ+uhRHQ2+ncDGWzoYWw+OqORZKT+D52G/NgaiE+Bpagzc3KCIqe9QrJumNoPIXZpPJM6Ih7i2L1UACe678Ykk5gsE278H0wLUlllzHjSjMqA3r8HN4VJYjV2tq9+Efu4LC3WxaxDr+pkfGFulGE m1coheJk 43vB5LnqKieGV4wcMmEgNkabk/YSuxc+oVWgckM2d42Tzx2xzbrWiP+zZfe0F4DWEXjW6lP0wBWNa2wSpZxonuvFWx5FCNpeP+KQ7aP3cNUsU8W3wjhnA5ArKBYPV9HtCu7PipAMvvqa3YGVS/11IiFnEOvz/SvxdL3rqcldoNa2zs4TuuqtFBIEO/fInT8nI3RlVYIvgMHloGWbto3ABnyfIfrPRaNxf70Q5YDziUJIo9BewYkQFd1r0n3O/P+AOvZLG7gDrccajwnXKxEyspR4iRUluSsQ/IgK5Ly/M3d4O7+9d+EoTCiopO7+6BAee/JXxZLZlo8fZgOv89wACH8G+NFspiZQ4ELrEQP/oyUVmMRdXJpdefJu8HTq/0OYZD4jbyZtaKUny50JqZHVG1X8m1E7dSmhGndrBOf+31UPsQMlyBxTgh/yoKSskOIOnsy7TOwgAPaX7EV1d04splQ0N8gzSvXS+qg/QuB9SvX7LKpUm9TxDW8T/FbOpR1suV6XIVQpcFXyOR0gmQZscw71EKqSDf9jnccOmScidBDqNhGAjBLCFBM0upJSvS4sIONr1 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: List-Subscribe: List-Unsubscribe: On 6/5/24 5:14 PM, David Hildenbrand wrote: > On 05.06.24 11:10, Alex Shi wrote: >> >> >> On 6/5/24 3:26 PM, David Hildenbrand wrote: >>> On 04.06.24 15:02, Alex Shi wrote: >>>> >>>> >>>> On 6/4/24 6:45 PM, David Hildenbrand wrote: >>>>> On 04.06.24 12:26, Alex Shi wrote: >>>>>> >>>>>> >>>>>> On 6/4/24 4:07 PM, David Hildenbrand wrote: >>>>>>> On 04.06.24 06:24, alexs@kernel.org wrote: >>>>>>>> From: "Alex Shi (tencent)" >>>>>>>> >>>>>>>> We can put off the flush action util a merging is realy coming. That >>>>>>>> could reduce some unmerge page flushing. >>>>>>>> BTW, flushing only do at arm, mips and few other archs. >>>>>>>> >>>>>>> >>>>>>> I'm no expert on that flushing, but I thought we would have to do the flushing before accessing page content -- before calculating the checksum etc. >>>>>>> >>>>>>> Now you would only do it before the pages_identical() check, but not when calculating the checksum. >>>>>>> >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thanks a lot for comments! >>>>>> >>>>>> If calc_checksum() is wrong before pages_idential(), (that's just after page was write_protected, that's a real guarantee for page context secured) pages_identical could recheck and make thing right. >>>>>> >>>>> >>>>> Yes, but you would get more wrong checksums, resulting in more unnecessary pages_identical() checks. >>>>> >>>>> That is missing from the description, and why we want to change that behavior. >>>>> >>>>> What's the net win? >>>>> >>>>>> And as to 2 flush functions here, I didn't see the guarantee for other writer from any other place. So maybe we should remove these flush action? >>>>> >>>>> "I didn't see the guarantee for other writer from any other place" can you rephrase your comment? >>>>> >>>>> If you mean "the process could modify that page concurrently", then you are right. But that's different than "the process modified the page in the past and we are reading stale content because we missed a flush". >>>> >>>> >>>> Maybe moving the flush before checksum could relief some worries. :) >>>> But still no one knows what flush really help, since if page content only syncs to memory by the flush, the kernel or process can't be work with current code. >>> >>> Please explain to me why we care about moving the flushs at all :) >>> >>> If they are NOP on most architectures either way, why not simply leave them there and call it a day? >> Uh, 2 reasons: >> 1, it uses page and can't convert to folio now. >> 2, as you pointed, flush action w/o page reading seems just waste time. > > Alex, I don't think the approach you take for coming up with the current set of patches is a good idea. > > Please reconsider what you can actually convert to folios and what must stay pages for now due to support for large folios in that code. > > Then, please explain properly why changes are required and why they are safe. > > For example, for in scan_get_next_rmap_item() we really *need* the page and not just the folio. So just leave the flushing there and be done with it. > Hi David, Thanks a lot for your review. Though all patches are passed in kernel selftest, but if we do care the saving more than quick processing, the main purpose of this patchset is gone. I'll drop this series. Thanks Alex