linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Mike Travis <mike.travis@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Russ Anderson <russ.anderson@hpe.com>,
	Andrew Banman <andrew.banman@hpe.com>,
	jgross@suse.com, dan.j.williams@intel.com,
	kirill.shutemov@linux.intel.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting
Date: Wed, 16 May 2018 13:09:09 +0200	[thread overview]
Message-ID: <20180516110909.GN12670@dhcp22.suse.cz> (raw)
In-Reply-To: <6a67bfcd-c80f-b0bd-aeb3-3c8d27d45e88@hpe.com>

On Tue 15-05-18 09:08:10, Mike Travis wrote:
[...]
> Hi Michal,
> 
> I will add more info but this patch does not address anything about
> incomplete memblocks.  They have existed in 2GB mem block size form since
> 2009 (v2.6) with the first UV1 system release.  I am not changing any of
> that handling.
> 
> The fixing part was to adapt to what Intel BIOS was using as a different
> boundary to align the PMEM NVDIMMs.  This is explained in both patch 1 and
> patch 2:
> 
> "Add a new function to "adjust" the current fixed UV memory block size of
> 2GB so it can be changed to a different physical boundary.  This is out of
> necessity so UV BIOS can accommodate Intel BIOS changes for NVDIMM's, which
> can align these new PMEM modules at other than 2GB boundaries."
> 
> "Add a call to the new function to "adjust" the current fixed UV memory
> block size of 2GB so it can be changed to a different physical boundary.
> This accommodates changes in the Intel BIOS, and therefore UV BIOS, which
> now can align boundaries different than the previous UV standard of 2GB. It
> also flags any UV Mem boundaries that cause a change in the mem block size
> boundary."
> 
> I can't explain why the Intel BIOS changed the boundaries, it probably has
> something to do with accommodating other areas of the NVDIMMs physical
> address space.  This caused a boundary alignment to be less than 2GB which
> UV had been using.  From one of the UV BIOS engineers I found out that Intel
> really only guarantees a 64MB boundary (which is actually less than the
> current Linux minimum of 128MB.)  Our own UVHUB requirements dictated that
> 2GB was an acceptable boundary up until now.
> 
> So let me know how much more info is needed on how I need to explain _this_
> change.

Thanks for the additional information. It helps to some extend but still
feel rather magic. It doesn't explain why this is UV specific and
require an UV specific fix. Why cannot we fix the generic hotplug code
instead and potentially allow other 128 unaigned memory ranges instead?
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-05-16 11:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 23:18 [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting mike.travis
2018-05-10 23:18 ` [PATCH 1/3] x86/platform/UV: Add adjustable set memory block size function mike.travis
2018-05-11  5:24   ` Greg KH
2018-05-10 23:18 ` [PATCH 2/3] x86/platform/UV: Use new " mike.travis
2018-05-11  5:24   ` Greg KH
2018-05-10 23:18 ` [PATCH 3/3] x86/platform/UV: Add kernel parameter to set memory block size mike.travis
2018-05-11  5:24   ` Greg KH
2018-05-11  5:24 ` [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting Greg KH
2018-05-11  6:48 ` Michal Hocko
2018-05-15 16:08   ` Mike Travis
2018-05-16 11:09     ` Michal Hocko [this message]
2018-05-24 20:17 mike.travis

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 \
    --in-reply-to=20180516110909.GN12670@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.banman@hpe.com \
    --cc=dan.j.williams@intel.com \
    --cc=dimitri.sivanich@hpe.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.travis@hpe.com \
    --cc=mingo@redhat.com \
    --cc=russ.anderson@hpe.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).