[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb793919-df5d-42cc-6b2e-d387e0faa42e@intel.com>
Date: Thu, 16 Apr 2020 15:38:38 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH, RFC] x86/mm/pat: Restore large pages after fragmentation
On 4/16/20 3:12 PM, Kirill A. Shutemov wrote:
> We already have it in kernel: CONFIG_CPA_DEBUG. It messes up with the
> mapping every 30 seconds. It is pretty good for the change too. It
> produces a lot of 2M/1G pages to be restored. I run it over night in my
> setup and it survives.
That's good for stability, and thanks for running it! (and please add
that nugget to the changelog)
It's good that you see it restoring some mappings, but, does it restore
*all* the 1G/2M pages that it started with (minus the ones that were
fractured for other reasons)? That should be pretty easy to check for.
Powered by blists - more mailing lists