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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4602EC433F5 for ; Fri, 22 Oct 2021 21:58:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C5D4E61040 for ; Fri, 22 Oct 2021 21:58:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C5D4E61040 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4DCBD940008; Fri, 22 Oct 2021 17:58:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48D08940007; Fri, 22 Oct 2021 17:58:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 306A0940008; Fri, 22 Oct 2021 17:58:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id 1E1CC940007 for ; Fri, 22 Oct 2021 17:58:43 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D27098249980 for ; Fri, 22 Oct 2021 21:58:42 +0000 (UTC) X-FDA: 78725438484.06.4169665 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf16.hostedemail.com (Postfix) with ESMTP id EC9BAF000099 for ; Fri, 22 Oct 2021 21:58:38 +0000 (UTC) Received: by mail-pf1-f176.google.com with SMTP id t184so4869104pfd.0 for ; Fri, 22 Oct 2021 14:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=46+z3KX/Bw5iK9i97ch1szfrniwqQXL3ZMhrfUJYmJ4=; b=GSC3K9lzPP51HWJwei47eKc+OBCVdcdVlBoyks9BJEcC8OIXr9fWeGJ50E1/Uvgz7m 8akD6yaJZb9fZ38FHuc82VZNIQ0D2MsSiYGcn7TaS241qd61moEDti59lCe+owWZLRQ8 nPYaUt4pFIfBgIThkonwMQv0uwtB77jkLDDIcBwc6C3wLjLimOxd3tmTBaymohvaL5gU JukOxKcLL9Eam56rNufU1/EtqKjV8AxbzCSXkoraci6Imam/QrNEK7EZOPGrvVXXBmBj Omv7AeJ2g/UoKbLgQzO1k0tqd5G/dFBE+fjPF58P+D7/d/Tp6xrZnPtL7HpoKverAwrH gLIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=46+z3KX/Bw5iK9i97ch1szfrniwqQXL3ZMhrfUJYmJ4=; b=UBJl9P4gw9onQoZOGne0srhKcEcbBwpv6tyNoDoXBlNubu6rXFrq151rAR/TUp9+wW u2a04+sPtF/kUjxsIeMxg4WN50l/v2EQVvKTdc+wfwDaCT1DJvTTof9iOuLXflU5g/BS N2KOmWeYsW3EtJFvwpDIqcJKZyvPN0xyQwLYz7VXkS5R78M2yP3Ob+cyNCIn81juJC5L PI0PE2rzKTXxolIkv+Minyf1A96aMmPfn/ecD0I+4bRJHf9qoMR9a+zAkTKkfUZNZxcr gC89RkbF6IlwA0dN+CVz19wDRSumk0/2WB3lFIRgPFKJ4gYgnxabo8f6JrQnQmUUPOTA YNdg== X-Gm-Message-State: AOAM533mUlbDx1yDfQ1e0Kh7rXHPK3w/o1dauWUPGkeeMIjrGx38DVy6 ZEREoEA2mm3YXFHEMruYuv8= X-Google-Smtp-Source: ABdhPJyKRqV6NreYrq0O0o2ilKwZvjQQpb2270LjJgj01yHsXs4Z+AIQyyklUagcK8sLt6DpD0TmuQ== X-Received: by 2002:a63:77c4:: with SMTP id s187mr1785536pgc.50.1634939921221; Fri, 22 Oct 2021 14:58:41 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id h2sm9921385pjk.44.2021.10.22.14.58.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Oct 2021 14:58:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [PATCH v2 0/5] mm/mprotect: avoid unnecessary TLB flushes From: Nadav Amit In-Reply-To: <20211021200450.b13499c379a27dbfefe9f5e3@linux-foundation.org> Date: Fri, 22 Oct 2021 14:58:39 -0700 Cc: Linux-MM , LKML , Andi Kleen , Andrea Arcangeli , Andrew Cooper , Andy Lutomirski , Dave Hansen , Peter Xu , Peter Zijlstra , Thomas Gleixner , Will Deacon , Yu Zhao , Nick Piggin , x86@kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E576E79-E4FD-4CB9-8BE5-142230C12E63@gmail.com> References: <20211021122112.592634-1-namit@vmware.com> <20211021200450.b13499c379a27dbfefe9f5e3@linux-foundation.org> To: Andrew Morton X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EC9BAF000099 X-Stat-Signature: 3xdt9ge3dgcatsicyxnb3ntturpe9mme Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GSC3K9lz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-HE-Tag: 1634939918-583584 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 Oct 21, 2021, at 8:04 PM, Andrew Morton = wrote: >=20 > On Thu, 21 Oct 2021 05:21:07 -0700 Nadav Amit = wrote: >=20 >> This patch-set is intended to remove unnecessary TLB flushes. It is >> based on feedback from v1 and several bugs I found in v1 myself. >>=20 >> Basically, there are 3 optimizations in this patch-set: >> 1. Avoiding TLB flushes on change_huge_pmd() that are only needed to >> prevent the A/D bits from changing. >> 2. Use TLB batching infrastructure to batch flushes across VMAs and >> do better/fewer flushes. >> 3. Avoid TLB flushes on permission demotion. >>=20 >> Andrea asked for the aforementioned (2) to come after (3), but this >> is not simple (specifically since change_prot_numa() needs the number >> of pages affected). >=20 > [1/5] appears to be a significant fix which should probably be > backported into -stable kernels. If you agree with this then I = suggest > it be prepared as a standalone patch, separate from the other four > patches. With a cc:stable. There is no functionality bug in the kernel. The Knights Landing bug was circumvented eventually by changing the swap entry structure so the access/dirty bits would not overlap with the swap entry data. >=20 > And the remaining patches are a performance optimization. Has any > attempt been made to quantify the benefits? I included some data before [1]. In general the cost that is saved is the cost of a TLB flush/shootdown. I will modify my benchmark to test huge-pages (which were not included in the previous patch-set) and send results later. I would also try nodejs to see if there is a significant enough benefit. Nodejs crashed before (hence the 3rd patch added here), as it exec-protects/unprotects pages - I will see if the benefit shows in the benchmarks. [ The motivation behind the patches is to later introduce userfaultfd writeprotectv interface, and for my use-case that is under=20 development this proved to improve performance considerably. ] [1] = https://lore.kernel.org/linux-mm/DA49DBBB-FFEE-4ACC-BB6C-364D07533C5E@vmwa= re.com/=