All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nadav Amit <nadav.amit@gmail.com>
To: Peter Xu <peterx@redhat.com>
Cc: Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Huang Ying <ying.huang@intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>, Hugh Dickins <hughd@google.com>,
	Andi Kleen <andi.kleen@intel.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>
Subject: Re: [PATCH v2 0/2] mm: Remember a/d bits for migration entries
Date: Thu, 4 Aug 2022 15:17:44 -0700	[thread overview]
Message-ID: <8FBBFD68-3315-48D6-B318-4AA5A170C0C8@gmail.com> (raw)
In-Reply-To: <20220804203952.53665-1-peterx@redhat.com>

On Aug 4, 2022, at 1:39 PM, Peter Xu <peterx@redhat.com> wrote:

>  (1) Page Idle Tracking
> 
>  Before this series, idle tracking can cause false negative if an accessed
>  page got migrated, since after migration the young bit will get lost.
>  After this series, it'll be better in that after migration young bit will
>  be persisted, so it'll be able to be detected correctly by page idle
>  logic when walking the pgtable.
> 
>  However there's still nothing done when page idle reset was carried out
>  during migration procedure in progress, but that should be a separate
>  topic to be addressed (e.g. to teach rmap pgtable walk code to be able to
>  walk with both present ptes and migration ptes).

IIUC, when a migration entry is set page_remove_rmap() is called by
try_to_migrate_one(), so improving page-idle accuracy should be done in a
different way.


      parent reply	other threads:[~2022-08-04 22:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04 20:39 [PATCH v2 0/2] mm: Remember a/d bits for migration entries Peter Xu
2022-08-04 20:39 ` [PATCH v2 1/2] mm/swap: Add swp_offset_pfn() to fetch PFN from swap entry Peter Xu
2022-08-04 20:39 ` [PATCH v2 2/2] mm: Remember young/dirty bit for page migrations Peter Xu
2022-08-04 22:40   ` Nadav Amit
2022-08-05 16:30     ` Peter Xu
2022-08-09  8:45       ` Huang, Ying
2022-08-09  8:47         ` David Hildenbrand
2022-08-09 14:59         ` Peter Xu
2022-08-05 12:17   ` David Hildenbrand
2022-08-05 16:36     ` Peter Xu
2022-08-09  8:40   ` Huang, Ying
2022-08-09 17:59     ` Peter Xu
2022-08-10  0:53       ` Huang, Ying
2022-08-10 19:21         ` Peter Xu
2022-08-11  5:44           ` Alistair Popple
2022-08-04 22:17 ` Nadav Amit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8FBBFD68-3315-48D6-B318-4AA5A170C0C8@gmail.com \
    --to=nadav.amit@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=peterx@redhat.com \
    --cc=vbabka@suse.cz \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.