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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28023C433E1 for ; Mon, 27 Jul 2020 18:06:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC64220714 for ; Mon, 27 Jul 2020 18:06:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="QRF3/pic" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC64220714 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 898046B0005; Mon, 27 Jul 2020 14:06:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8495E6B0006; Mon, 27 Jul 2020 14:06:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 760166B0007; Mon, 27 Jul 2020 14:06:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 5FD416B0005 for ; Mon, 27 Jul 2020 14:06:58 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CF5E38248D52 for ; Mon, 27 Jul 2020 18:06:57 +0000 (UTC) X-FDA: 77084636874.13.bee68_250683126f63 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id B2F3E1802409C for ; Mon, 27 Jul 2020 18:05:16 +0000 (UTC) X-HE-Tag: bee68_250683126f63 X-Filterd-Recvd-Size: 5164 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Jul 2020 18:05:16 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id s16so3041653ljc.8 for ; Mon, 27 Jul 2020 11:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zf1DcpFR73FQ/K5FpriSp27xsNldHKArEydUx2BFKFU=; b=QRF3/picVvgRWWmzmFq0wZbKwEE4LSOxQykmIZsqG3hLahOVwHE+jLLn+0akmNB/tg SRSA1r6RjQCYdK3yI+zwsQ8YLd7jIpfOo+CHuKta6ogtIwzw9Tx5Tq5asCTyyRvZFQDg xuKPaAdx9HEFVuUwJGCy23CmrJZIQKshrHAAs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zf1DcpFR73FQ/K5FpriSp27xsNldHKArEydUx2BFKFU=; b=Z6y/cffV/x1dhgkIKkU/GKqnPS5sUBzAtsshql9ix6grIYnCTA7oY7MwSiaLIaIMvV DfVoMXZGHS71rkMoum9HHC6iXw/OAKGjGb8ulb2muJg8wHMOPCDyrIXcB6a55709qJXD DT8T6vLHX0F57e2L5wLKX5x1id0r0vP9ssbMO2yGFwvSnwKmKxFLLiWgdu3UPM+oV/H+ L/s84rPQq+w7PRXR1TcsHAS8SlPOjllBJkcTUnezy1gxJJi2omYOyJcg35i/NKYcMZVV v94rOx/vVPwVKhk6bpmH8ht3O5ImmQ543ZtV8cwEjwpKXtjold6OHTmkVINNxZhtEifO /NVQ== X-Gm-Message-State: AOAM533sANtcAksm3bULDfW4YGEHzVrehhC+GbgFzmjKUdNHm+puT+NV nua62GqNHHk+pVeRJfo/thcc9lMkMiQ= X-Google-Smtp-Source: ABdhPJw/xupPH6DHOc+s48LfkAJuWMYBeV47eRyzgg2JR9J10aHRSoY+z09m6rWG0eksaz83SxARmA== X-Received: by 2002:a2e:859a:: with SMTP id b26mr11473018lji.241.1595873114154; Mon, 27 Jul 2020 11:05:14 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id f18sm2487590ljn.73.2020.07.27.11.05.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2020 11:05:12 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id q6so18255665ljp.4 for ; Mon, 27 Jul 2020 11:05:11 -0700 (PDT) X-Received: by 2002:a2e:991:: with SMTP id 139mr10206879ljj.314.1595873111130; Mon, 27 Jul 2020 11:05:11 -0700 (PDT) MIME-Version: 1.0 References: <20200723211432.b31831a0df3bc2cbdae31b40@linux-foundation.org> <20200724041508.QlTbrHnfh%akpm@linux-foundation.org> <7de20d4a-f86c-8e1f-b238-65f02b560325@linux.alibaba.com> <45015c63-e719-a58a-7d07-6c156273a890@linux.alibaba.com> In-Reply-To: <45015c63-e719-a58a-7d07-6c156273a890@linux.alibaba.com> From: Linus Torvalds Date: Mon, 27 Jul 2020 11:04:55 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault To: Yang Shi Cc: Andrew Morton , Catalin Marinas , Johannes Weiner , Hillf Danton , Hugh Dickins , Josef Bacik , "Kirill A . Shutemov" , Linux-MM , mm-commits@vger.kernel.org, Will Deacon , Matthew Wilcox , Yu Xu Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B2F3E1802409C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Mon, Jul 27, 2020 at 10:52 AM Yang Shi wrote: > > It looks normal page is skipped too unless it is a write fault. The > comment might be a little bit misleading. No the comment is fine - in that it matches the code. It's the code _and_ the comment that I find to be garbage. > Read fault should just change young bit and typically TLB won't get > flushed if just young bit is changed and TLB flush can be deferred again > to write fault which may change access permission and/or dirty bit. This is the part I disagree with. A read fault could easily cause the exact same issue, exactly because people do young bits in software too. It's just harder to trigger, because the young bit is typically set initially - in ways that the dirty bit easily isn't. So to get to the "on, young bit wasn't set, the TLB has the 'fault on access' bit set, *and* we raced on two different CPU's at the same time" condition is much *much* harder than the write bit is. But it seems to be no different in theory. So I think the whole "treat write/dirty specially" thing is complete garbage. Sure, it speeds things up. But it speeds things up by being wrong. Linus