Message-ID: <20150903184029.GV8051@wotan.suse.de>
Date:	Thu, 3 Sep 2015 20:40:29 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	Stuart Hayes <stuart.w.hayes@...il.com>, tglx@...utronix.de,
	mingo@...hat.com, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	mcgrof@...not-panic.com, Toshi Kani <toshi.kani@...com>
Subject: Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup

On Thu, Sep 03, 2015 at 02:10:14PM -0400, Prarit Bhargava wrote:
> 
> 
> On 09/03/2015 01:59 PM, Luis R. Rodriguez wrote:
> > On Thu, Sep 03, 2015 at 08:17:02AM -0400, Prarit Bhargava wrote:
> >>
> >>
> >> On 09/02/2015 10:45 PM, Luis R. Rodriguez wrote:
> >>> On Mon, Aug 31, 2015 at 11:05:33AM -0500, Stuart Hayes wrote:
> >>>> Increase the range of chunk sizes tried in mtrr_cleanup() so it is able
> >>>> to map large memory configs into MTRRs.
> >>>>
> >>>> Currently, mtrr_cleanup() will fail with large memory configurations,
> >>>> because it limits chunk_size to 2GB, which means that each MTRR can only
> >>>> cover 2GB of memory.  With a memory size of, say, 256GB, and ten variable
> >>>> MTRRs (such as some recent Intel CPUs have), it is not possible to set up
> >>>> the MTRRs to cover all of memory.
> >>>
> >>> Linux drivers no longer use MTRR so why is the cleanup needed, ie, what would
> >>> happen if the cleanup is just skipped in your case ?
> >>
> >> The infiniband & video drivers still use MTRR (or at least it was my
> >> understanding that they do). 
> > 
> > There were a few stragglers left on v4.2, I have transformed them in the latest
> > development changes and those tranformations are now part of linux-next. If
> > this is specific to a driver you may want to first ensure you backport the
> > required patch that transforms the driver to use proper PAT interfaces, v4.2
> > should have most updates but there were still a few left. Just make sure your
> > driver doesn't call mtrr_add() directly and if it doesn't then you should be
> > OK.
> > 
> >> In any case, Stuart -- could you try booting with
> >> 'disable_mtrr_cleanup' as a kernel parameter?
> > 
> > Indeed, please I'd like to hear back. Be sure to have the respective driver
> > transformation in place, what driver are you using exactly? In the event that
> > you argue this is still needed I'd like to know exaclty *why*, the comit log
> > does not mention any of that at all.
> > 
> 
> Well ... we are trying to also fix this in older kernels too, *cough* RHEL
> *cough*, so that's where the patch comes from.  If upstream is going to
> deprecate/remove mtrr support so be it. 

Check linux-next, and Documentation/x86/mtrr.txt

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/x86/mtrr.txt

The platform use of MTRR is the only thing you should be concerned over but as
noted returning MTRR_TYPE_INVALID should suffice if the OS does not make
any driver use / modifications.

Another next step I was considering was to then take out PAT initialization
code out from MTRR's so that we can enable distros disable MTRR but enable
PAT. Right now this is not possible. If there is really a need for MTRR
cleanup now's the time to discuss this then, I'd like to know precicely
why it'd be needed if the OS does not make any direct use of it.

> We can do a stable fix instead to fix older stable kernels.

Patches to stable depend on them being merged first on Linus' tree so
we'd need to queue this up for linux-next if you want that, but again,
best to first check *why* you need this other than some "some error comes
up" type of thing.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists