public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Daniel J Blueman <daniel@numascale.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, Steffen Persvold <sp@numascale.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH] x86: Drop redundant memory-block sizing code
Date: Thu, 6 Nov 2014 12:56:37 +0100	[thread overview]
Message-ID: <20141106115636.GA4318@pd.tnic> (raw)
In-Reply-To: <545B5735.8000401@numascale.com>

On Thu, Nov 06, 2014 at 07:10:45PM +0800, Daniel J Blueman wrote:
> "As the first check for 64GB or larger memory returns a 2GB memory
> block size in that case, the following check for less than 64GB will
> always

Right, but why isn't there a simple else? Instead, the >64GB case is
looking at totalram_pages but the so-called else case is looking at
max_pfn. Why, what's the difference?

My purely hypothetical suspicion is this thing used to handle some
special case with memory holes where totalram_pages was still < 64GB but
max_pfn was above. I'm looking at this memory block size approximation
downwards which supposedly used to do something at some point, right?

Now, when you remove this, it doesn't do so anymore, potentially
breaking some machines.

Or is this simply unfortunate coding and totalram_pages and max_pfn are
equivalent?

Questions over questions... Maybe it is time for some git log
archeology...

:-)

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-11-06 11:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ojh5M-xh-17@gated-at.bofh.it>
2014-11-06  4:50 ` [PATCH] x86: Drop redundant memory-block sizing code Daniel J Blueman
2014-11-06  9:40   ` Borislav Petkov
2014-11-06 10:33     ` Daniel J Blueman
2014-11-06 10:40       ` Borislav Petkov
2014-11-06 11:10         ` Daniel J Blueman
2014-11-06 11:56           ` Borislav Petkov [this message]
2014-11-10  9:03             ` Daniel J Blueman
2014-11-10 16:11               ` Borislav Petkov

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=20141106115636.GA4318@pd.tnic \
    --to=bp@alien8.de \
    --cc=bhelgaas@google.com \
    --cc=daniel@numascale.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sp@numascale.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@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