From: Toshi Kani <email@example.com> To: "Luis R. Rodriguez" <firstname.lastname@example.org>, Prarit Bhargava <email@example.com> Cc: Stuart Hayes <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, "H. Peter Anvin" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Toshi Kani <email@example.com> Subject: Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup Date: Thu, 03 Sep 2015 13:22:42 -0600 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20150903184029.GV8051@wotan.suse.de> On Thu, 2015-09-03 at 20:40 +0200, Luis R. Rodriguez wrote: > 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/Docume > ntation/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. The following sentence in the "mtrr.txt" is not correct. (Sorry I should have caught it earlier.) mtrr_type_lookup() returns MTRR_TYPE_INVALID when MTRRs are disabled, i.e. MTRRs are not set by neither firmware nor OS. Most of the firmwares enable them, though. "If MTRRs are only set up by the platform firmware code though and the OS does not make any specific MTRR mapping requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID." Thanks, -Toshi
next prev parent reply other threads:[~2015-09-03 19:25 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <55E477DE.email@example.com> 2015-08-31 16:05 ` Stuart Hayes 2015-09-03 2:45 ` Luis R. Rodriguez 2015-09-03 12:17 ` Prarit Bhargava 2015-09-03 17:59 ` Luis R. Rodriguez 2015-09-03 18:10 ` Prarit Bhargava 2015-09-03 18:40 ` Luis R. Rodriguez 2015-09-03 19:22 ` Toshi Kani [this message] 2015-09-03 19:51 ` Luis R. Rodriguez 2015-09-03 21:31 ` Toshi Kani 2015-09-03 22:07 ` Luis R. Rodriguez 2015-09-03 22:25 ` Toshi Kani 2015-09-03 22:45 ` Luis R. Rodriguez 2015-09-03 23:21 ` Toshi Kani 2015-09-03 23:54 ` Luis R. Rodriguez 2015-09-04 0:48 ` Toshi Kani 2015-09-04 1:40 ` Luis R. Rodriguez 2015-09-04 14:56 ` Toshi Kani 2015-09-04 6:51 ` Jan Beulich 2015-09-14 14:46 ` Stuart Hayes 2015-11-05 19:14 ` Yinghai Lu 2015-11-05 19:43 ` Luis R. Rodriguez 2016-03-16 20:20 ` Luis R. Rodriguez 2016-03-29 17:07 ` Luis R. Rodriguez
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.