linux-kernel - Re: [PATCH RFC 0/4] mm: Remember young bit for migration entries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YumKlqjv8PaafpER@xz-m1.local>
Date:   Tue, 2 Aug 2022 16:35:34 -0400
From:   Peter Xu <peterx@...hat.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Huang Ying <ying.huang@...el.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Nadav Amit <nadav.amit@...il.com>,
        Hugh Dickins <hughd@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH RFC 0/4] mm: Remember young bit for migration entries

On Tue, Aug 02, 2022 at 10:23:49PM +0200, David Hildenbrand wrote:
> > 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?

Exactly, so I'm also wondering whether we can move the swp pte anon
exclusive bit into swp entry.  It just sounds weird to have them defined in
two ways.

> 
> > 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.

The swap type address space is still limited, I'd say we should save when
possible.  I believe people caring about swapping care about the limit of
swap devices too.  If the offset can keep it, I think it's better than the
swap type.  De-dup either the type or the swap pte bit would be nicer, imho.

-- 
Peter Xu