linux-kernel - Re: [PATCHv9 00/14] mm, x86/cc: Implement support for unaccepted memory

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] [day] [month] [year] [list]

Date:   Mon, 17 Apr 2023 09:37:42 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Sean Christopherson <seanjc@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Joerg Roedel <jroedel@...e.de>,
        Ard Biesheuvel <ardb@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Dario Faggioli <dfaggioli@...e.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Mike Rapoport <rppt@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        marcelo.cerri@...onical.com, tim.gardner@...onical.com,
        khalid.elmously@...onical.com, philip.cox@...onical.com,
        aarcange@...hat.com, peterx@...hat.com, x86@...nel.org,
        linux-mm@...ck.org, linux-coco@...ts.linux.dev,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv9 00/14] mm, x86/cc: Implement support for unaccepted
 memory

On 4/16/23 21:19, Kirill A. Shutemov wrote:
> On Mon, Apr 03, 2023 at 04:42:54PM +0200, Vlastimil Babka wrote:
>> Hmm yeah it can be noisy. Did you try to only count events that have
>> fragmenting=1 and/or MIGRATE_MOVABLE as fallback_migratetype? As those are
>> the really bad events.
> 
> I finally got around to retest it.
> 
> 		total	fragmenting	movable	fragmenting&&movable
> base-1:		957	583		353	0
> base-2:		2715	2343		359	0
> base-3:		2033	1669		353	0
> patched-1:	1325	929		371	0
> patched-2:	2844	2451		371	0
> patched-3:	1304	917		361	0
> 
> fragmenting=1 is defined as fallback_order<pageblock_order which is most
> of them.
> 
> Patched kernel showed slightly elevated movable(fallback_migratetype=1)
> cases. Is it critical?

Maybe it's still not statistically significant anyway, also not as cricical
as fragmenting&movable.

> There's no allocations that is fragmenting and movable. Hm.

It probably means your test wasn't stressfull enough to inflict a mix of
rapid movable an unmovable allocations when memory is nearly full. But at
that point the memory is all accepted, so we don't need such scenario. The
important thing is that this kind of events didn't start happening during
the gradual memory accepting phase.