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 CC08FC00140 for ; Wed, 10 Aug 2022 06:30:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34EF48E0003; Wed, 10 Aug 2022 02:30:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FE0C8E0001; Wed, 10 Aug 2022 02:30:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1ED738E0003; Wed, 10 Aug 2022 02:30:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 113FF8E0001 for ; Wed, 10 Aug 2022 02:30:41 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E07ABC114E for ; Wed, 10 Aug 2022 06:30:40 +0000 (UTC) X-FDA: 79782709440.07.B6914A5 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf03.hostedemail.com (Postfix) with ESMTP id 364FB2002A for ; Wed, 10 Aug 2022 06:30:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660113040; x=1691649040; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=gB7X2rsLImjBhNl6pbwqqOhUegeSwjxLluoazpjeH1E=; b=X8QACC54MQDyzW0KhEh3WnK9jlAU+XMVEQlioEgODk0O4nIBcPlBYGfw eEzO8Y/ZCqYlI5X1VGGhmppRRXhVysLUZ8jgQkPJTAHrrozpj9PFJ2rhj TDBn8DeNR3psmIFpVV7W7ZZMfU0cw8E3c0qXcdDTDqtcdqsSjTnZi/MTJ UnWbWBVuU2KaoliOYdtJ9j2Z2zGT8sUtFzcIZqNsqiVYkiy6b+GtEdb6H yKxhZudOkEaxpRsWX63Bv4CWts5JU1mIB3rXm41V57y1RrwUZNMYCBDG/ W4c9VQaDQjVK5RPTx4NjiUXsI734LclhEcHgV0wFNUNbr0/4aoI5ku9u7 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10434"; a="291797808" X-IronPort-AV: E=Sophos;i="5.93,226,1654585200"; d="scan'208";a="291797808" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2022 23:30:38 -0700 X-IronPort-AV: E=Sophos;i="5.93,226,1654585200"; d="scan'208";a="673182402" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2022 23:30:36 -0700 From: "Huang, Ying" To: Peter Xu 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 References: <20220809220100.20033-1-peterx@redhat.com> <20220809220100.20033-6-peterx@redhat.com> Date: Wed, 10 Aug 2022 14:30:33 +0800 In-Reply-To: <20220809220100.20033-6-peterx@redhat.com> (Peter Xu's message of "Tue, 9 Aug 2022 18:00:58 -0400") Message-ID: <8735e4fw52.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660113040; a=rsa-sha256; cv=none; b=swupcWLXL8LLTP+nEnIBLlyJJhsuxcCw0cEZBqlhQ/v5PvH8pfvabCkaLscciLYcEPR7Z9 OywEGokwd7lngBOEOJE0XX6rY4GE89di5dIJclmINDDqASBiAmPkSWvt8KhDxNpfcZMoy9 ZYmP3xNIb438roS3uoKNtRmhc/71R8E= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=X8QACC54; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660113040; 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=V6OXmDrmb/05+reAfsfp1jN72h872V87MaUwDtUqwSc=; b=0IK1KzVboRzogAEdQt0go0Y0N/ESuBaJOpdAPF59ocRKUUNdpYOG7ytoB95lYRu6pnysA5 tq3MBCPmR0Zq5oTLITeb1/r7NvW4s7Y+sYRyp19sKCVvr79rPgqjzPRTdgbwzzEQo8qhzD zbnKbDyOhnuLkaUVANt4m8/lsD+Fhyo= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 364FB2002A Authentication-Results: imf03.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=X8QACC54; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Stat-Signature: cknu4fqnq1ttaujpskk55nsjx7cg1mzg X-HE-Tag: 1660113039-184788 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: 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 > 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. Best Regards, Huang, Ying