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 35A64C43334 for ; Wed, 15 Jun 2022 15:25:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DD306B0071; Wed, 15 Jun 2022 11:25:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 98C7D6B0072; Wed, 15 Jun 2022 11:25:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 855B36B0074; Wed, 15 Jun 2022 11:25:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 78D346B0071 for ; Wed, 15 Jun 2022 11:25:23 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 341B512023A for ; Wed, 15 Jun 2022 15:25:23 +0000 (UTC) X-FDA: 79580844126.29.957A6D3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 9666C400A6 for ; Wed, 15 Jun 2022 15:25:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655306722; 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: in-reply-to:in-reply-to:references:references; bh=YSV8Fve0PWJWjvGISeUvIz6MGKTc1wSANb5wMGR0pmg=; b=amiZr5UC1nInramqDbMkS2BnIxw4xVKb7jikw8W9Ul1/KK0+Wea4bjzh7SlWDmljErkEQ8 1BdYeOoGbP5mFcHPLuFvgrGhApJnmo5aEi7vZRPr9aWvZkoEEjiDzgWi9a2YComLI3h35G E1Bc0n38yf419kMZRn8p4izBKJWcqtg= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-342-X1A7iTW0NKaAZ4jBGcjmgA-1; Wed, 15 Jun 2022 11:25:20 -0400 X-MC-Unique: X1A7iTW0NKaAZ4jBGcjmgA-1 Received: by mail-il1-f200.google.com with SMTP id 3-20020a056e0220c300b002d3d7ebdfdeso8573066ilq.16 for ; Wed, 15 Jun 2022 08:25:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YSV8Fve0PWJWjvGISeUvIz6MGKTc1wSANb5wMGR0pmg=; b=KnGCqFNIMK2xoijaoKwlVEwXU2y0CM2/quLs9T5i7hJorDh+S89ZXYYaixBCkeaNKF FT0R3fvOJEAvs7/AkFQuAYTvibYyjJNun2NYSDQ69Yz7c8tv9JfvZjzjXVAuHv36C8Q0 tpASzVKxwMB+Iuu7RrjDJveU/77OpHCDECaiVxiFIp+vIrHkwNZo9EDSBTEIEQUSdQoy 3KrY+eqd1SmX/7w8QHN7ofkWhTgoIIo0h5gQvvwaioDiXSlKdMnwBUTjhzgQRzdf6Bib 32GASqAudpGN61ivc6GTCYg0RTMniFLJTzULVh/jtvT5NsMRg5/5TyjaK4Eoi4cQR93/ 4slA== X-Gm-Message-State: AJIora+vF8eCL+djXR5toG4IBg3imp6ha265wcNhKaXlR0yBGtOZr81r G3SxrIAc+x1YqjUX5nE49qJerDyoFU1xdMqZACBAWSZ8l8kb0REuPEX3VsEzbkjWScHdKGUz215 NdKpmw0cgxzo= X-Received: by 2002:a05:6638:3389:b0:331:f5e7:7dda with SMTP id h9-20020a056638338900b00331f5e77ddamr141588jav.93.1655306720030; Wed, 15 Jun 2022 08:25:20 -0700 (PDT) X-Google-Smtp-Source: AGRyM1slD1TjvGX5JJWBPTslwwpNrUl1Q6gp1EonDIoeya0vuNqPpOHgr5IBRc0spdE9e/6rqYU6cA== X-Received: by 2002:a05:6638:3389:b0:331:f5e7:7dda with SMTP id h9-20020a056638338900b00331f5e77ddamr141568jav.93.1655306719806; Wed, 15 Jun 2022 08:25:19 -0700 (PDT) Received: from xz-m1.local (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id f16-20020a056638119000b00331f32a48fdsm4372036jas.11.2022.06.15.08.25.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jun 2022 08:25:19 -0700 (PDT) Date: Wed, 15 Jun 2022 11:25:17 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Peter Collingbourne , Linus Torvalds , Andrew Morton , Nadav Amit , Dave Hansen , Andrea Arcangeli , Yang Shi , Hugh Dickins , Mel Gorman Subject: Re: [PATCH v3] mm/mprotect: try avoiding write faults for exclusive anonymous pages when changing protection Message-ID: References: <20220614093629.76309-1-david@redhat.com> MIME-Version: 1.0 In-Reply-To: <20220614093629.76309-1-david@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655306722; a=rsa-sha256; cv=none; b=Bv2Cx/p/m4H9LkvIdNoTxGl7iAEMkE4F6lvATcCwZT1aHFVzZido9y6ANvSVmG3odZReSQ j1uraOyPTuMxZw96TQRfwMZk++RzjzMeV3tLPZnbfyQOagfIXVawlwaIPOeSASJ98+jwv1 0On+EQHqPEnCBvOceJVOERscuQXFDuM= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=amiZr5UC; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf01.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655306722; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YSV8Fve0PWJWjvGISeUvIz6MGKTc1wSANb5wMGR0pmg=; b=Ah9AthmZIndFQGL4tUOkGX2lWl7Yo8ETMqh/LceMGRvbuvCe6inUiQqzuq5eyM2xWQCrtu oddNt3hfBbbIzuKxcrwTVPtnCwUAPD55w3qUnpLnMCOKv7UaC2VMjRe5m83Gy3bFvFhHXg tGV1nAm8ZB+t4SS69/I5AamiFMvSgtU= X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 9666C400A6 X-Stat-Signature: ybx6sruhgzjqpoj6hen7o6mqqwhgb1mc Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=amiZr5UC; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf01.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-HE-Tag: 1655306722-712009 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 Tue, Jun 14, 2022 at 11:36:29AM +0200, David Hildenbrand wrote: > Similar to our MM_CP_DIRTY_ACCT handling for shared, writable mappings, we > can try mapping anonymous pages in a private writable mapping writable if > they are exclusive, the PTE is already dirty, and no special handling > applies. Mapping the anonymous page writable is essentially the same thing > the write fault handler would do in this case. > > Special handling is required for uffd-wp and softdirty tracking, so take > care of that properly. Also, leave PROT_NONE handling alone for now; > in the future, we could similarly extend the logic in do_numa_page() or > use pte_mk_savedwrite() here. > > While this improves mprotect(PROT_READ)+mprotect(PROT_READ|PROT_WRITE) > performance, it should also be a valuable optimization for uffd-wp, when > un-protecting. > > This has been previously suggested by Peter Collingbourne in [1], > relevant in the context of the Scudo memory allocator, before we had > PageAnonExclusive. > > This commit doesn't add the same handling for PMDs (i.e., anonymous THP, > anonymous hugetlb); benchmark results from Andrea indicate that there > are minor performance gains, so it's might still be valuable to streamline > that logic for all anonymous pages in the future. > > As we now also set MM_CP_DIRTY_ACCT for private mappings, let's rename > it to MM_CP_TRY_CHANGE_WRITABLE, to make it clearer what's actually > happening. I'm personally not sure why DIRTY_ACCT cannot be applied to private mappings; it sounds not only for shared but a common thing. I also don't know whether "change writable" could be misread too anyway. Say, we're never changing RO->RW mappings with this flag, but only try to unprotect the page proactively when proper, from that POV Nadav's suggestion seems slightly better on using "unprotect". No strong opinion, the patch looks correct to me, and thanks for providing the new test results, Acked-by: Peter Xu -- Peter Xu