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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 377B4C00140 for ; Wed, 10 Aug 2022 15:19:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C76D36B0071; Wed, 10 Aug 2022 11:19:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C25E56B0072; Wed, 10 Aug 2022 11:19:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC6F36B0073; Wed, 10 Aug 2022 11:19:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9A78F6B0071 for ; Wed, 10 Aug 2022 11:19:57 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 792941A0655 for ; Wed, 10 Aug 2022 15:19:57 +0000 (UTC) X-FDA: 79784043234.19.351B16C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 192FA180047 for ; Wed, 10 Aug 2022 15:19:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660144796; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FficIWOFeLjuHiM92gf0Vr7lpmb8nVxpiEgSclxrqmQ=; b=fEbtuvdfJDYLDCJOH8l65Ck4VTA8Izz2zVwoOfwUAneBnF/XFiREGWIPXV3UxdAB+mtwFZ pc5z9AmovQk7HAjZ8pKugX0Dew12N5DgNFA7LMm+NHfrFG+7GuOVUvl8GtXvFSzPiQW+Pp U8GJmeGSf07ZO5K/4HxztE5sTzOZe1U= Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-425-lnHJ2PQ_OXao8syJ-hYt4g-1; Wed, 10 Aug 2022 11:19:54 -0400 X-MC-Unique: lnHJ2PQ_OXao8syJ-hYt4g-1 Received: by mail-il1-f197.google.com with SMTP id w6-20020a056e021a6600b002dea6904708so10678148ilv.6 for ; Wed, 10 Aug 2022 08:19:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=FficIWOFeLjuHiM92gf0Vr7lpmb8nVxpiEgSclxrqmQ=; b=ZMg7hDHCIKZ9AggkDsSTIlckDjvn7qQS1ANkYG3pih3cS750ybpFiviBGlQXDNhgl3 TghnGtUMSqHjqYl/uWM4qG59BNd5G1JWANd9uiz3NFOTwKTbCx6/MxtV6lsm7HFRynVH 4VOP017zQEK5kv/SbCYqHheu7iZu81ot7gJItoLHpMWSwZxzwv9phLM5Wr4Cje+OC9pR 7L12ZeqOFUuTSf5NymOQLRQ1BkSINLm80/nBhW6nDvbNzY/0LJxmozAIy+YDRmdPjOW5 nj98LE4BlQwheBp1VWglxG03Q/uk+76Px2MYFbwaBZrt1HIZ4jzgv8gsKJCeOz/hKkVx 0TOA== X-Gm-Message-State: ACgBeo3G/tEUdvLgRetXaVr01fWHGi8V8zkzFA2hDuomLPqaV1t1Ms0L q3kTZ6q4Ek8WQxAK5Bv5ulgnUwkBqHhEuScPZx8UuPOKXTNcdKgAj0m2V7Vil0zpBoeCPjYFdOG Qp+atlRe5IYw= X-Received: by 2002:a92:b742:0:b0:2de:14d8:e801 with SMTP id c2-20020a92b742000000b002de14d8e801mr13434701ilm.105.1660144793993; Wed, 10 Aug 2022 08:19:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR7WuT8iDHEqyGrGAlUMRx9BNUhHDxYjZWfu4PnuArLauU6rsVNMbUKyZQ96Lx+d1VEnx9IHog== X-Received: by 2002:a92:b742:0:b0:2de:14d8:e801 with SMTP id c2-20020a92b742000000b002de14d8e801mr13434687ilm.105.1660144793701; Wed, 10 Aug 2022 08:19:53 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-35-70-27-3-10.dsl.bell.ca. [70.27.3.10]) by smtp.gmail.com with ESMTPSA id k8-20020a056e02156800b002dc100ab6fdsm2271969ilu.35.2022.08.10.08.19.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 08:19:53 -0700 (PDT) Date: Wed, 10 Aug 2022 11:19:51 -0400 From: Peter Xu To: "Huang, Ying" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , David Hildenbrand , Nadav Amit , Andrew Morton , Hugh Dickins , Vlastimil Babka , Andrea Arcangeli , Andi Kleen , "Kirill A . Shutemov" Subject: Re: [PATCH v3 5/7] mm: Remember young/dirty bit for page migrations Message-ID: References: <20220809220100.20033-1-peterx@redhat.com> <20220809220100.20033-6-peterx@redhat.com> <8735e4fw52.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <8735e4fw52.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660144797; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FficIWOFeLjuHiM92gf0Vr7lpmb8nVxpiEgSclxrqmQ=; b=HoSzpFv2Cnh5VcpoRfzqrcoTAqOdxLG5enKxJPRRiLbhcKp6ILCNHNxluZuoyWNBbGWeJZ WAcQPhvujY5iGKHjhjGi4EG2wC1v6T2B6uGQzC9mMuRJDbILiJcOkBe/GVcBdZg+bMjz1t loEW24S2eQCEMgS5is3BybxnvNlyVy8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fEbtuvdf; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660144797; a=rsa-sha256; cv=none; b=VFSAVWM9YroDX0IrrlftG8fbMFwSkuIN8QR7LkA7JMMo/dW8vRfaZ/v3vE1N2svWCTntgS 9nz4JlF574rfqgfi/FxeAx+5pIOy+k/OLXcE/reG7xCMQE3EV+eciwXVPscLl1qcY8QT6/ vijsqqzRJFWGPDRP7mdreP9YOxLXS08= X-Stat-Signature: hdcz8ibocq58tuzzcid66gr67x5qkrgx X-Rspamd-Queue-Id: 192FA180047 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fEbtuvdf; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1660144796-262058 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 Wed, Aug 10, 2022 at 02:30:33PM +0800, Huang, Ying wrote: > Peter Xu writes: > > > When page migration happens, we always ignore the young/dirty bit settings > > in the old pgtable, and marking the page as old in the new page table using > > either pte_mkold() or pmd_mkold(), and keeping the pte clean. > > > > That's fine from functional-wise, but that's not friendly to page reclaim > > because the moving page can be actively accessed within the procedure. Not > > to mention hardware setting the young bit can bring quite some overhead on > > some systems, e.g. x86_64 needs a few hundreds nanoseconds to set the bit. > > The same slowdown problem to dirty bits when the memory is first written > > after page migration happened. > > > > Actually we can easily remember the A/D bit configuration and recover the > > information after the page is migrated. To achieve it, define a new set of > > bits in the migration swap offset field to cache the A/D bits for old pte. > > Then when removing/recovering the migration entry, we can recover the A/D > > bits even if the page changed. > > > > One thing to mention is that here we used max_swapfile_size() to detect how > > many swp offset bits we have, and we'll only enable this feature if we know > > the swp offset can be big enough to store both the PFN value and the young > ~~~~~ > Nitpick: A/D Fixed. > > > bit. Otherwise the A/D bits are dropped like before. > > > > Signed-off-by: Peter Xu > > --- > > include/linux/swapops.h | 99 +++++++++++++++++++++++++++++++++++++++++ > > mm/huge_memory.c | 18 +++++++- > > mm/migrate.c | 6 ++- > > mm/migrate_device.c | 4 ++ > > mm/rmap.c | 5 ++- > > 5 files changed, 128 insertions(+), 4 deletions(-) > > > > diff --git a/include/linux/swapops.h b/include/linux/swapops.h > > index e1accbcd1136..0e9579b90659 100644 > > --- a/include/linux/swapops.h > > +++ b/include/linux/swapops.h > > @@ -8,6 +8,10 @@ > > > > #ifdef CONFIG_MMU > > > > +#ifdef CONFIG_SWAP > > +#include > > +#endif /* CONFIG_SWAP */ > > I don't think we need the comment here. The #ifdef is too near. But > this isn't a big deal. I'd slightly prefer keeping it (especially Nadav used to complain on missing comments on ifdefs in previous versions..) since any ifdef can grow by adding code into it. Then it'll be hard to justify how to define "near" or not, so hard to define who should be adding that if I'm not the one. Thanks, -- Peter Xu