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 3636BC6FD1C for ; Tue, 14 Mar 2023 09:16:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9F3F8E0003; Tue, 14 Mar 2023 05:16:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4F508E0002; Tue, 14 Mar 2023 05:16:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F1288E0003; Tue, 14 Mar 2023 05:16:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7F5B98E0002 for ; Tue, 14 Mar 2023 05:16:17 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4E9C8AB677 for ; Tue, 14 Mar 2023 09:16:17 +0000 (UTC) X-FDA: 80566947594.07.28080D1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 1AAF9100011 for ; Tue, 14 Mar 2023 09:16:14 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YOlrEyVJ; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1678785375; 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=Xf81muVPDC5//DWpZWbv9f3l2qAvarAaNW0E95fz61w=; b=HwLklcUFnVQZt14YpCBGvdNSF20BXp+2AdEeRIPSpjGJXex9Ibojibh9XyMOIFo1DvzdJr dqPvlAObbHPbY0W/vBQFtgvQxgsK2wJ1qCZofhRfabLjjUyzZvLXzNIsx6DLlmpDmEUJnF TLtoY4Ng2BUGY5NNNZh8uMZ043ToSfs= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YOlrEyVJ; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1678785375; a=rsa-sha256; cv=none; b=caCUsBJNHPHCJcWjbScuc/9vNyIiR2EdkDWKjf7RcP2QYNw8plgITZEtHmdjhULi4DptPI OFk9uH2+Rp/1RLNiQyYrJeavmUNooyCZbPrcwqE4ayLDagGWpRSbXMfpTlvckDVoeYU+MP 6y2jg44rwVe/bA+zdfUdP5+177RqA4I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678785374; 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=Xf81muVPDC5//DWpZWbv9f3l2qAvarAaNW0E95fz61w=; b=YOlrEyVJGi7UYFji0mwV97IwJsMOE1icBPIJ1TB760ua4i7N4EzwwM/XLftDFRJt+/tM5h 7UL/aUNfiJH5s62anTnciiW3FT4cgy/rRhl7EzqbPj74RXqjNh+P3fV2QQi/7zRHAckFxe TBq9NS7tl5+kGal/koOyMkFZ8mlh0B0= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-541-oc22wnGcNfWp3MdMbCBUlw-1; Tue, 14 Mar 2023 05:16:12 -0400 X-MC-Unique: oc22wnGcNfWp3MdMbCBUlw-1 Received: by mail-wm1-f70.google.com with SMTP id l23-20020a7bc457000000b003e206cbce8dso5220891wmi.7 for ; Tue, 14 Mar 2023 02:16:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678785371; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xf81muVPDC5//DWpZWbv9f3l2qAvarAaNW0E95fz61w=; b=b0dV4eku5ZvEVIp7p0zmGI3gvwsM8GlxbzPT1MqzoeUh2y7jwuoUNZA+Ixg0sL+wp4 CHZQg5tHZdHFrcutL8BeAGDGtfk16uNInucZPh783E5kVg2EhGwi31Sce9KOV4B/GEga 4ZhX/dBy1OMXCTkSsdIqlMTqZqpOWPDuUyDKM3oMO3xUo9o4YLsnuGUVywx6LYLiVjaw py4OSGcNruUCbVXSkx9e49u1jlBjPpYT0YT6Y3E8G+hlDLUUdXZs7GZSKwCIfesscbL4 hMBSNFixDhNi7HOnWoxSv0/UxFmbYCKCdaryIeAJBP49ThV5S0nGzpP3la9yZLsb8zyQ 4p+A== X-Gm-Message-State: AO0yUKXWKWiu8VoxpsSs8K05kXNLZ6nM4/YwMwh1XS8bVfcrmdwn1A2S 44JuMOMilCs3+ghXlJ78/VfXZSGiE5ZNWcW0OHvJUJOoPLIapk/9uqsDypFZqm4WjGHETXrY10U tE8wRJuvdkcc= X-Received: by 2002:a5d:624a:0:b0:2c8:42b5:8022 with SMTP id m10-20020a5d624a000000b002c842b58022mr19308457wrv.59.1678785371652; Tue, 14 Mar 2023 02:16:11 -0700 (PDT) X-Google-Smtp-Source: AK7set8i8fZoBmfDEIQKhhQK/OXO65PhWgzfENfMbVJO9gle9lw0m/WsjwWfCyI74QGeYZZlug6wrg== X-Received: by 2002:a5d:624a:0:b0:2c8:42b5:8022 with SMTP id m10-20020a5d624a000000b002c842b58022mr19308437wrv.59.1678785371329; Tue, 14 Mar 2023 02:16:11 -0700 (PDT) Received: from ?IPV6:2003:cb:c704:1000:21d5:831d:e107:fbd6? (p200300cbc704100021d5831de107fbd6.dip0.t-ipconnect.de. [2003:cb:c704:1000:21d5:831d:e107:fbd6]) by smtp.gmail.com with ESMTPSA id n3-20020adff083000000b002c70d97af78sm1508493wro.85.2023.03.14.02.16.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Mar 2023 02:16:10 -0700 (PDT) Message-ID: <5b38c161-7615-30f0-f3b8-6b770e2a74ed@redhat.com> Date: Tue, 14 Mar 2023 10:16:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v4 0/5] batched remove rmap in try_to_unmap_one() To: Yin Fengwei , Andrew Morton Cc: linux-mm@kvack.org, willy@infradead.org, mike.kravetz@oracle.com, sidhartha.kumar@oracle.com, naoya.horiguchi@nec.com, jane.chu@oracle.com References: <20230313124526.1207490-1-fengwei.yin@intel.com> <20230313114900.96cfad6c3e4b684646f74e61@linux-foundation.org> From: David Hildenbrand Organization: Red Hat In-Reply-To: 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-Rspamd-Queue-Id: 1AAF9100011 X-Stat-Signature: jbbb8bs6akr9pc4gdpdpdqc1y56rkjfb X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678785374-66969 X-HE-Meta: U2FsdGVkX1+x4jo4u/qq9/cUp1p4Y87oR2HNTdiznyhcWkRcAoi1yL8BgKquikR8b+JpEPjxqrvIIRZxWifHPz8AIqXbff7Cu7AzwZr0CorO3ysqXdrYw59E0YAZze+9R5GwG49wfj8kj5xKH8usCiVWULvfIL5KGiK8T1XP0GfZyJPkiQUqhUPU2Yol30nRHRKtInpnNH33e2zv81pkdFfdk49X3YF09YrjFuJB9rbEhc7XGIcPp/YBiHsIriADAoNKD+xt7Lfs6uT6RTsHvyMOstGybtJjEM0HjiqjIChjRk9WbeAhWPNJYpVjlb8Az/J7ejA3Ns1duBUYZH4Rf0QtoYOE1NwWmTJ2foo2QJC/EObh1/4oy6z6xFTNaHHWABduuZWyc3oSNg6ZRGncRrcOR8wEoig8xX99H8kE6dLl4eABMApzFRSiMaBwpKyQvQoebaNKiz3NkEfW3yr2WE8CzL7i+gsbHLilp6i9yBSy9GU3Hsa55t+xiQESATpUxCzdPEPOf2ke0PN7d+jdBl0avPt8mIv6WnFZwHyxySXG7FfjryncSn/G+WZBUW2pGHkabZgOqgoQNBn1drYWXOxcDcOgWYzkoyj8nDzC7YEggJdInfdv8FseNgoZCui1owXSxu4ClTXLw0wbBoEstyDflTbtvgWN5Qp82rgYu1pbT56ADJPUCCaSI07yMXbduaXqLTqZwVRn+ssqaGwW8U0raedmBOeak2XJvHf9JUMEfjXZb7fYRZFqSWbY7/e8A4YnbRVyd2IkeNdLRbDtYGIP/hGx+Cij2UtlzQb1vhVE4GJNUMi4svs9phq+6+HGnOW+pRHMqKlWs5KOHAg70uP1brY9GWywmv8m22vxBcsnuFs4Pd6fr7QUXiOSQ/xn2Xeafc2vzdZDfcIXP0kf4+Ka75qX17v7NUeavQ6rPU621dLEskOIxFexvI9gZe3BQXzcbq204aK4VgSWxpW AsdwHs/q yoa5NyMvvMMU5vvshKUo0uALKMPxkYtptHq5Ut+tdKmSN/3/VaCWS7yvI62y1W4MRr5hXH349+XLGiTARHXbdnB8TkXTwtLsIjeQADBdA54aftAcRDuT8gSsoyq2Zdj6Z7lfZd4wnWJrLg6Xy3Nn7lUUKYYmJLFy70LG7OpKvoXKxAx1LA0pTJQaCr4D9A+++HemO9N3wvLX2Jf1KaHK6EPTvViBWpjVQuWyptCjuGntS2V1/Q0MokYHQmCBra8Knq8gMxg7Faxm8IB/XpKl5b+z6vZIUmBj4jbrTpBabaLa337+rQUXziIg0WlFADmitctzBMkk8Y2d7yChaDqHm0VZLfuNsKL/MMFFMtPWKTr24eSgPPvt1BjmrXWlOJ746whcR3zQTyWpjN1poyqG8+GLFHOmgDVTsaV1eXOiGaGUZG8yd9Hv4kz+A41it2XRd4O6w7j82rs2Ph77jGoM0gSx3Xw== 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 14.03.23 04:09, Yin Fengwei wrote: > On 3/14/23 02:49, Andrew Morton wrote: >> On Mon, 13 Mar 2023 20:45:21 +0800 Yin Fengwei wrote: >> >>> This series is trying to bring the batched rmap removing to >>> try_to_unmap_one(). It's expected that the batched rmap >>> removing bring performance gain than remove rmap per page. >>> >>> This series reconstruct the try_to_unmap_one() from: >>> loop: >>> clear and update PTE >>> unmap one page >>> goto loop >>> to: >>> loop: >>> clear and update PTE >>> goto loop >>> unmap the range of folio in one call >>> It is one step to always map/unmap the entire folio in one call. >>> Which can simplify the folio mapcount handling by avoid dealing >>> with each page map/unmap. >>> >>> ... >>> >>> For performance gain demonstration, changed the MADV_PAGEOUT not >>> to split the large folio for page cache and created a micro >>> benchmark mainly as following: >> >> Please remind me why it's necessary to patch the kernel to actually >> performance test this? And why it's proving so hard to demonstrate >> benefits in real-world workloads? >> >> (Yes, this was touched on in earlier discussion, but I do think these >> considerations should be spelled out in the [0/N] changelog). > OK. What about add following in cover letter: > " > The performance gain of this series can be demonstrated with large > folio reclaim. In current kernel, vmscan() path will be benefited by > the changes. But there is no workload/benchmark can show the exact > performance gain for vmscan() path as far as I am aware. > > Another way to demonstrate the performance benefit is using > MADV_PAGEOUT which can trigger page reclaim also. The problem is that > MADV_PAGEOUT always split the large folio because it's not aware of > large folio for page cache currently. To show the performance benefit, > MADV_PAGEOUT is updated not to split the large folio. > > For long term with wider adoption of large folio in kernel (like large > folio for anonymous page), MADV_PAGEOUT needs be updated to handle > large folio as whole to avoid splitting it always. Just curious what the last sentence implies. Large folios are supposed to be a transparent optimization. So why should we pageout all surrounding subpages simply because a single subpage was requested to be paged out? That might harm performance of some workloads ... more than the actual split. So it's not immediately obvious to me why "avoid splitting" is the correct answer to the problem at hand. -- Thanks, David / dhildenb