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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 02BB8C433E0 for ; Wed, 23 Dec 2020 00:57:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 456AE221F7 for ; Wed, 23 Dec 2020 00:57:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 456AE221F7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 73E066B0092; Tue, 22 Dec 2020 19:57:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C7296B009B; Tue, 22 Dec 2020 19:57:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5406D6B009E; Tue, 22 Dec 2020 19:57:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 386936B0092 for ; Tue, 22 Dec 2020 19:57:16 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 05301180AD837 for ; Wed, 23 Dec 2020 00:57:16 +0000 (UTC) X-FDA: 77622733272.21.paper10_160ce5827464 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id DE54C180442C0 for ; Wed, 23 Dec 2020 00:57:15 +0000 (UTC) X-HE-Tag: paper10_160ce5827464 X-Filterd-Recvd-Size: 5287 Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Dec 2020 00:57:13 +0000 (UTC) Received: from ambrosehua-HP-xw6600-Workstation (unknown [196.245.9.36]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Dxr8vWleJfyMEDAA--.4294S2; Wed, 23 Dec 2020 08:57:02 +0800 (CST) Date: Wed, 23 Dec 2020 08:56:52 +0800 From: Huang Pei To: Nicholas Piggin Cc: Hugh Dickins , linux-mm@kvack.org, Bibo Mao , Linus Torvalds , linux-arch@vger.kernel.org, linux-mips@vger.kernel.org Subject: Re: [PATCH v3 3/3] mm: optimise pte dirty/accessed bit setting by demand based pte insertion Message-ID: <20201223005651.bviywoihdzzlm3z6@ambrosehua-HP-xw6600-Workstation> References: <20201220045535.848591-1-npiggin@gmail.com> <20201220045535.848591-4-npiggin@gmail.com> <1608606460.clzumasfvm.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1608606460.clzumasfvm.astroid@bobo.none> User-Agent: NeoMutt/20171215 X-CM-TRANSID:AQAAf9Dxr8vWleJfyMEDAA--.4294S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCw4xXr4fXFy5GrWxuFykZrb_yoW5XFyfpF WrGan0yan8JF1xtw4Iyw17ZFySvrWfXFZ8XFn0gryjv39xWF97tr4I9ayY9FyDCr4kCa1j vF13Xa4DZF4DuFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyKb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxkIecxEwVCF1wCF04k20xvY0x0E wIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E74 80Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0 I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04 k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY 1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUqEoXUUUUU X-CM-SenderInfo: xkxd0whshlqz5rrqw2lrqou0/ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000053, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, On Tue, Dec 22, 2020 at 01:24:53PM +1000, Nicholas Piggin wrote: > Excerpts from Hugh Dickins's message of December 22, 2020 4:21 am: > > Hi Nick, > > > > On Sun, 20 Dec 2020, Nicholas Piggin wrote: > > > >> Similarly to the previous patch, this tries to optimise dirty/accessed > >> bits in ptes to avoid access costs of hardware setting them. > >> > >> This tidies up a few last cases where dirty/accessed faults can be seen, > >> and subsumes the pte_sw_mkyoung helper -- it's not just architectures > >> with explicit software dirty/accessed bits that take expensive faults to > >> modify ptes. > >> > >> The vast majority of the remaining dirty/accessed faults on kbuild > >> workloads after this patch are from NUMA migration, due to > >> remove_migration_pte inserting old/clean ptes. > > > > Are you sure about this patch? It looks wrong to me: because isn't > > _PAGE_ACCESSED (young) already included in the vm_page_prot __S001 etc? > > > > I haven't checked all instances below, but in general, that's why the > > existing code tends not to bother to mkyoung, but does sometimes mkold > > (admittedly confusing). > > There might have been one or two cases where it didn't come directly > from vm_page_prot, but it was a few rebases and updates ago. I did see > one or two places where powerpc was taking faults. Good point though I > can test again and see, and I might split the patch. > > > > > A quick check on x86 and powerpc looks like they do have _PAGE_ACCESSED > > in there; and IIRC that's true, or ought to be true, of all architectures. > > > > Maybe not mips, which I see you have singled out: I remember going round > > this loop a few months ago with mips, where strange changes were being > > proposed to compensate for not having that bit in their vm_page_prot. > > I didn't follow through to see how that ended up, but I did suggest > > mips needed to follow the same convention as the other architectures. > > Yeah the main thing is to try get all architectures doing the same thing > and get rid of that sw_mkyoung too. Given the (Intel) x86 result of the > heavy micro-fault, I don't think anybody is special and we should > require them to follow the same behaviour unless it's proven that one > needs something different. > > If we can get all arch to set accessed in vm_page_prot and get rid of > most of these mkyoung()s then all the better. And it actually looks like > MIPS may be changing direction: > > https://lore.kernel.org/linux-arch/20200919074731.22372-1-huangpei@loongson.cn/ > > What's the chances of that going upstream for the next merge window? It > seems like the right thing to do. Any comment on V4: https://lore.kernel.org/linux-arch/20201019081257.32127-1-huangpei@loongson.cn/ > > Thanks, > Nick Thanks, Huang Pei