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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 C918AC433DB for ; Tue, 22 Dec 2020 03:25:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C25422B51 for ; Tue, 22 Dec 2020 03:25:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C25422B51 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A79B68D0007; Mon, 21 Dec 2020 22:25:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A29B88D0001; Mon, 21 Dec 2020 22:25:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9198A8D0007; Mon, 21 Dec 2020 22:25:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 7C30B8D0001 for ; Mon, 21 Dec 2020 22:25:01 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 35F188249980 for ; Tue, 22 Dec 2020 03:25:01 +0000 (UTC) X-FDA: 77619476802.05.pies84_1e034942745c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 20E411801DC38 for ; Tue, 22 Dec 2020 03:25:01 +0000 (UTC) X-HE-Tag: pies84_1e034942745c X-Filterd-Recvd-Size: 5811 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Dec 2020 03:25:00 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id be12so6711387plb.4 for ; Mon, 21 Dec 2020 19:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=RaIPy33YYEHJBauFMKe6av1pPOpX7ysWVTHsmm1YmMM=; b=ewOT59Q9HpQla5OCbUNuYsgXbMc8UhzAb+Znyajenyzz8BwWRCoAZgSTwmYWDMkF0W 5HMlPZgNEUaUqWG94oTI1QX/x2zNWvpyoFwdmJhNeWJr7ZEOb6v6q3os0P37EXZ+o9Cq Nk54nLNx1tvUUNqyZcDmu5Z0eGsOzS+gRsbXlvkrLfFP2tOB5sdT3nO0kTrfpcLI2PWr UjpRcZ4Z79RM2Ow9kDy1E463PuAByhGGXjmfrmszZO+NiMscBbvnLek9ylz2/nbuW+jy QGMFJNginIEiJVPO5aUVK5hVnU7ALVWMrlu1PUPzFDECCwn6HGgXmagXgyAjOYYZiGno zHUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=RaIPy33YYEHJBauFMKe6av1pPOpX7ysWVTHsmm1YmMM=; b=qcpYoeXMk3X1nLPuH3tRvbUcDZujfiyFpcmaQ6wrCqVqROwS7nkK2tS++/6sTTR+8S Jl6ZUWBDzsrtubgccdg67PTTBM4u64gocQHGJ1I3e21+jjpj6Qp7LOxEn2X0K+HOLkFR QdD2lTC/Tc38K9SzQP/6jwhWq3lcZJgnuiwI4St1n5lLKTrwjBLj9gNyoiDSbYhQubZH Eqd0/pEzt00Ez51Z1TTFdsNK8UNEnLL47uqpSwvIGxagDr+qMlkk+Mm19qWzUVyWXurO Gh8deyBsTtFBzfpvsTs6oU8DkbavU4hX4rZwYx9FUwp+4HKPft1c714ZEGXcMoKI83jk i8pw== X-Gm-Message-State: AOAM531J9tj4uhTH8ZlBskM4pPeaxes1BPLQYkZiZv+NkkAm4STbzWzG IolY7kPJbHWswsVN2lL0waA4J4CsdOA= X-Google-Smtp-Source: ABdhPJzkTvnjsHxReSw4V5fj0dM0Vu8lxpxM+IrNd8ypuWhbpX9Lip2Ep3vWvroEYcLFo35d/NhuoA== X-Received: by 2002:a17:902:778e:b029:da:feef:8f2d with SMTP id o14-20020a170902778eb02900dafeef8f2dmr19315658pll.25.1608607499815; Mon, 21 Dec 2020 19:24:59 -0800 (PST) Received: from localhost (193-116-97-30.tpgi.com.au. [193.116.97.30]) by smtp.gmail.com with ESMTPSA id c23sm3432480pgc.72.2020.12.21.19.24.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Dec 2020 19:24:59 -0800 (PST) Date: Tue, 22 Dec 2020 13:24:53 +1000 From: Nicholas Piggin Subject: Re: [PATCH v3 3/3] mm: optimise pte dirty/accessed bit setting by demand based pte insertion To: Hugh Dickins Cc: linux-mm@kvack.org, Bibo Mao , Linus Torvalds , Huang Pei , linux-arch@vger.kernel.org, linux-mips@vger.kernel.org References: <20201220045535.848591-1-npiggin@gmail.com> <20201220045535.848591-4-npiggin@gmail.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <1608606460.clzumasfvm.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Excerpts from Hugh Dickins's message of December 22, 2020 4:21 am: > Hi Nick, >=20 > On Sun, 20 Dec 2020, Nicholas Piggin wrote: >=20 >> Similarly to the previous patch, this tries to optimise dirty/accessed >> bits in ptes to avoid access costs of hardware setting them. >>=20 >> 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. >>=20 >> 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. >=20 > 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? >=20 > 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=20 can test again and see, and I might split the patch. >=20 > 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= . >=20 > 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=20 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=20 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. Thanks, Nick