[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210125145911.GF23070@zn.tnic>
Date: Mon, 25 Jan 2021 15:59:11 +0100
From: Borislav Petkov <bp@...en8.de>
To: Mike Rapoport <rppt@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Baoquan He <bhe@...hat.com>,
David Hildenbrand <david@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
Mike Rapoport <rppt@...ux.ibm.com>, Qian Cai <cai@....pw>,
Thomas Gleixner <tglx@...utronix.de>,
Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, x86@...nel.org
Subject: Re: [PATCH 1/2] x86/setup: consolidate early memory reservations
On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote:
> + trim_low_memory_range();
Btw, you can get rid of that one too:
/*
* Here we put platform-specific memory range workarounds, i.e.
* memory known to be corrupt or otherwise in need to be reserved on
* specific platforms.
*
* If this gets used more widely it could use a real dispatch mechanism.
*/
static void __init trim_platform_memory_ranges(void)
{
trim_snb_memory();
}
yeah, yeah, we can do a real dispatch mechanism but we didn't need one
since 2012 so I guess we can get rid of trim_platform_memory_ranges()
and call trim_snb_memory() directly and simplify it even more.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists