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=-6.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 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 A444AC433E0 for ; Mon, 27 Jul 2020 22:35:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 40FA5206D7 for ; Mon, 27 Jul 2020 22:35:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40FA5206D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8CFC36B0002; Mon, 27 Jul 2020 18:35:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 881126B0005; Mon, 27 Jul 2020 18:35:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 795D36B0006; Mon, 27 Jul 2020 18:35:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id 637656B0002 for ; Mon, 27 Jul 2020 18:35:17 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C2505181AC9B6 for ; Mon, 27 Jul 2020 22:35:16 +0000 (UTC) X-FDA: 77085313032.07.print60_0d156ee26f64 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 9C8EA1803F9B3 for ; Mon, 27 Jul 2020 22:35:16 +0000 (UTC) X-HE-Tag: print60_0d156ee26f64 X-Filterd-Recvd-Size: 3852 Received: from out30-57.freemail.mail.aliyun.com (out30-57.freemail.mail.aliyun.com [115.124.30.57]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Jul 2020 22:35:15 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R621e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=yang.shi@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0U40G8HE_1595889297; Received: from US-143344MP.local(mailfrom:yang.shi@linux.alibaba.com fp:SMTPD_---0U40G8HE_1595889297) by smtp.aliyun-inc.com(127.0.0.1); Tue, 28 Jul 2020 06:35:09 +0800 Subject: Re: [patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault To: Linus Torvalds 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 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> From: Yang Shi Message-ID: Date: Mon, 27 Jul 2020 15:34:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 9C8EA1803F9B3 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 7/27/20 11:04 AM, Linus Torvalds wrote: > 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. Yes, it seems so. It may just trigger "fault on access" again and again until someone else has TLB flushed. It sounds better to do local TLB flush (this may depend on architecture, some may need global flush) unconditionally for spurious fault except VM_FAULT_TRIED case. > > 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