Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1262005rwl; Fri, 24 Mar 2023 08:15:21 -0700 (PDT) X-Google-Smtp-Source: AKy350aCPF/t9vV0H4aiOgBQnceMwF46aDjFqkCYyEYtSTn4DjSqEAfBNyi47tAVdupEvfEzw5Kt X-Received: by 2002:a17:907:6e22:b0:930:3916:df1d with SMTP id sd34-20020a1709076e2200b009303916df1dmr4304150ejc.0.1679670921509; Fri, 24 Mar 2023 08:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679670921; cv=none; d=google.com; s=arc-20160816; b=r1fP3UK23bSzNf7XwtVOfUXYhmXtQ/KV4xXLaR+VHbfGSKmKfVtzuhMw6SG08dpczl VKmuB9NUDEdW+Kq3GIgMUoVaH1DCbuPDecLN6peEfVkbmKzsOtKBa0TSGNRoDwV4E9mG /bUFa+U60eCdUiUS157AUCTgr6pUs7w9eaM2cDJaR8Rhu15QybJFJ49GVScX7NAng4Yn ha2gEU34j11En0lEPzzNuoGOgCLU7oM76t5gc4aps9iNfnn9Omdu1cf4YL8yIjHOEPOz TDPJEsWszbOsgnR72Ai/LfBLtxXTrVFZXOp7miwIVN+b+8nTnB0NJKeiEyvdWi80UGWi WmBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=8uJj6EPj+UD3O21Pqn1G98WWv3xWLtmqX4YnUhEP8NU=; b=WhaKFO5Q81xRZaVJ4xm3V7D46LFBtzMa09iI7e52Hk8mhX4OzDMV8L3AnPyq0nKI3+ o95F9q6dN82vo8geW2TXi7knt5ElZMUvuhXJiOatYSmZurvgZaJamao2M4vthUFWyJYk 4hqL4H2mGZojT1quhfuFSldKlKe8SUGiuCRTu5zrsVratIf9DNE66yIQFsmGgnXGwjD8 RRVG4c1O+yanlX/OPPH4BkPOHFQP+7RT8hJTFG4vHES9+2GnQ3kw0Wjgc9wwVkvwZLk7 DQy2UA+NNbtHV6dNPSPdVmX753c8HQcOBB/NsBnjzGjezOGuapjsCp/Qvflo8J+aguyT MwOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=Vxu4i84z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n23-20020a17090695d700b00930c07c35c3si20221753ejy.847.2023.03.24.08.14.57; Fri, 24 Mar 2023 08:15:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=Vxu4i84z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231575AbjCXPL0 (ORCPT + 99 others); Fri, 24 Mar 2023 11:11:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232375AbjCXPLX (ORCPT ); Fri, 24 Mar 2023 11:11:23 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8F6119F2E; Fri, 24 Mar 2023 08:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=8uJj6EPj+UD3O21Pqn1G98WWv3xWLtmqX4YnUhEP8NU=; b=Vxu4i84z/vDjsISB7zvMxaSSV1 8WTOiUyzkFfe/IdsRmYVRN6SrMDc28w3mFzpErB0JvqAPcQkE7vnbdqRgYKwRp6cXso/CB5l74w3P yh/F0fCWSJJXiX3Bq5RgOwLJDaPppVluv+iaA9hhWNXUB3GXE6XpDsrxJH/FmYcdprayJndYczTj6 9lYJtnWQ64h6iy7c2DDgwV/oskwOf1JGM7p15GDfMPfl1NW1VnTTcWb5h1sNFLYptK1FiUg1+X34w 2LdbPU8lhk9VF14ZoX8dZHIKVVG2so24Q0xN41XUNJ5HUowKSNGFxccxygZ4Ieu+mgWwlpCVjtAjv C06NTeqw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pfj4G-0050pI-MU; Fri, 24 Mar 2023 15:11:00 +0000 Date: Fri, 24 Mar 2023 15:11:00 +0000 From: Matthew Wilcox To: Will Deacon Cc: "Yin, Fengwei" , Ryan Roberts , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 35/36] mm: Convert do_set_pte() to set_pte_range() Message-ID: References: <6dd5cdf8-400e-8378-22be-994f0ada5cc2@arm.com> <2fa5a911-8432-2fce-c6e1-de4e592219d8@arm.com> <12d7564f-5b33-bdcc-1a06-504ad8487aca@intel.com> <25bf8e75-cc2e-7d08-dbba-41c53ab751b0@arm.com> <20230324145828.GB27199@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230324145828.GB27199@willie-the-truck> X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 24, 2023 at 02:58:29PM +0000, Will Deacon wrote: > Yes, please don't fault everything in as young as it has caused horrible > vmscan behaviour leading to app-startup slowdown in the past: > > https://lore.kernel.org/all/20210111140149.GB7642@willie-the-truck/ > > If we have to use the same value for all the ptes, then just base them > all on arch_wants_old_prefaulted_pte() as iirc hardware AF was pretty > cheap in practice for us. I think that's wrong, because this is a different scenario. Before: We faulted in N single-page folios. Each page/folio is tracked independently. That's N entries on whatever LRU list it ends up on. The prefaulted ones _should_ be marked old -- they haven't been accessed; we've just decided to put them in the page tables to speed up faultaround. The unaccessed pages need to fall off the LRU list as quickly as possible; keeping them around only hurts if the workload has no locality of reference. After: We fault in N folios, some possibly consisting of multiple pages. Each folio is tracked separately, but individual pages in the folio are not tracked; they belong to their folio. In this scenario, if the other PTEs for pages in the same folio are marked as young or old doesn't matter; the entire folio will be tracked as young, because we referenced one of the pages in this folio. Marking the other PTEs as young actually helps because we don't take pagefaults on them (whether we have a HW or SW accessed bit). (can i just say that i dislike how we mix up our old/young accessed/not terminology here?) We should still mark the PTEs referencing unaccessed folios as old. No argument there, and this patch does that. But it's fine for all the PTEs referencing the accessed folio to have the young bit, at least as far as I can tell.