All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Huang Ying <ying.huang@intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Nadav Amit <nadav.amit@gmail.com>,
	Hugh Dickins <hughd@google.com>, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH RFC 0/4] mm: Remember young bit for migration entries
Date: Tue, 2 Aug 2022 22:23:49 +0200	[thread overview]
Message-ID: <24ffea6e-ca66-2b94-c682-48a42a655fd1@redhat.com> (raw)
In-Reply-To: <YumFs0jpCc/Mwjzf@xz-m1.local>

> I don't think we only care about x86_64?  Should other archs have the same
> issue as long as there's the hardware young bit?
> 
> Even without it, it'll affect page reclaim logic too, and that's also not
> x86 only.

Okay, reading the cover letter and looking at the code my understanding
was that x86-64 is the real focus.

>>
>>>
>>> Besides I actually have a question on the anon exclusive bit in the swap
>>> pte: since we have that anyway, why we need a specific migration type for
>>> anon exclusive pages?  Can it be simply read migration entries with anon
>>> exclusive bit set?
>>
>> Not before all arch support pte_swp_mkexclusive/pte_swp_exclusive/.
>>
>> As pte_swp_mkexclusive/pte_swp_exclusive/ only applies to actual swap
>> PTEs, you could even reuse that bit for migration entries and get at
>> alteast the most relevant 64bit architectures supported easily.
> 
> Yes, but I think having two mechanisms for the single problem can confuse
> people.
> 

It would be one bit with two different meanings depending on the swp type.

> IIUC the swap bit is already defined in major archs anyway, and since anon
> exclusive bit is best-effort (or am I wrong?..), I won't worry too much on

It kind-of is best effort, but the goal is to have all archs support it.

... just like the young bit here?

> archs outside x86/arm/ppc/s390 on having anon exclusive bit lost during
> migrations, because afaict the whole swap type of ANON_EXCLUSIVE_READ is
> only servicing that very minority.. which seems to be a pity to waste the

I have a big item on my todo list to support all, but I have different
priorities right now.

If there is no free bit, simply steal one from the offset ... which is
the same thing your approach would do, just in a different way, no?

> swp type on all archs even if the archs defined swp pte bits just for anon
> exclusive.

Why do we care? We walk about one type not one bit.

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2022-08-02 20:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29  1:40 [PATCH RFC 0/4] mm: Remember young bit for migration entries Peter Xu
2022-07-29  1:40 ` [PATCH RFC 1/4] mm/swap: Add swp_offset_pfn() to fetch PFN from swap entry Peter Xu
2022-08-01  3:13   ` Huang, Ying
2022-08-01 22:29     ` Peter Xu
2022-08-02  1:22       ` Huang, Ying
2022-07-29  1:40 ` [PATCH RFC 2/4] mm: Remember young bit for page migrations Peter Xu
2022-07-29  1:40 ` [PATCH RFC 3/4] mm/x86: Use SWP_TYPE_BITS in 3-level swap macros Peter Xu
2022-07-29  1:40 ` [PATCH RFC 4/4] mm/x86: Define __ARCH_SWP_OFFSET_BITS Peter Xu
2022-07-29 17:07 ` [PATCH RFC 0/4] mm: Remember young bit for migration entries Nadav Amit
2022-07-29 22:43   ` Peter Xu
2022-08-01  3:20 ` Huang, Ying
2022-08-01  5:33 ` Huang, Ying
2022-08-01 22:25   ` Peter Xu
2022-08-01  8:21 ` David Hildenbrand
2022-08-01 22:35   ` Peter Xu
2022-08-02 12:06     ` David Hildenbrand
2022-08-02 20:14       ` Peter Xu
2022-08-02 20:23         ` David Hildenbrand [this message]
2022-08-02 20:35           ` Peter Xu
2022-08-02 20:59             ` David Hildenbrand
2022-08-02 22:15               ` Peter Xu

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=24ffea6e-ca66-2b94-c682-48a42a655fd1@redhat.com \
    --to=david@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nadav.amit@gmail.com \
    --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.