LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Balbir Singh <bsingharora@gmail.com>,
	anton@ozlabs.org, linuxppc-dev@lists.ozlabs.org
Cc: npiggin@gmail.com, benh@kernel.crashing.org,
	alistair@popple.id.au, arbab@linux.vnet.ibm.com,
	Balbir Singh <bsingharora@gmail.com>,
	Michael Neuling <mikey@neuling.org>
Subject: Re: [PATCH] Revert "powerpc/powernv: Increase memory block size to 1GB on radix"
Date: Mon, 30 Apr 2018 20:43:09 +1000	[thread overview]
Message-ID: <874ljtrn42.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20180430083432.21546-1-bsingharora@gmail.com>

Balbir Singh <bsingharora@gmail.com> writes:
> This reverts commit 53ecde0b9126ff140abe3aefd7f0ec64d6fa36b0.

Firstly everything here only applies to Radix, so we need to say that.

> The commit above changed the memblock size to 1GiB, which did some
> nice things like create fewer TLB entries for mapping memory at
> the time of hotplug.

You say TLB entry here and below, but I think that's misleading. We
don't create TLB entries for mappings at the time of hotplug. We create
entries in the page tables.

And is it true that changing the memory block size to 256MB necessarily
means we'll never create a 1GiB mapping? It looks like if you call
arch_add_memory() with a 1GiB block it will create 1GiB mappings.

I agree if we add 256MB blocks individually then we won't use a 1GiB
mapping.

But I'm not sure any of the above is all that relevant, because we
didn't make the change to 1GiB for any of those reasons, we did it to
prevent the kernel crashing.

If we *did* want to change the block size for 1GiB for performance
reasons then we need a commit that justifies that.

> The downside is that it changes the granularity
> at which memory can be hot-plugged and hot-unplugged. The implication
> is that if we had less than a 1GiB to hot-plug/hot-unplug that
> would not be possible.

That 2nd sentence is not strong enough, it should say something more
like: It forces hot(un)plug to operate at a 1GiB granularity.

> The reason we had this fix was to resolve an issue where we did not
> split mappings on hot-unplug, leaving a TLB entry that spanned the
> region that was unplugged. This is now fixed by 4dd5f8a99e79 which
> splits the page table, removing the MMU mappings for the hot-unplugged
> region correctly.

I'd say:

This commit was a stop-gap to prevent crashes on hotunplug, caused by
the mismatch between the 1G mappings used for the linear mapping and the
memory block size. Those issues are now resolved because we split the
linear mapping at hotunplug time if necessary, as implemented in commit
4dd5f8a99e79 ("powerpc/mm/radix: Split linear mapping on hot-unplug").

cheers

  parent reply	other threads:[~2018-04-30 10:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-30  8:34 [PATCH] Revert "powerpc/powernv: Increase memory block size to 1GB on radix" Balbir Singh
2018-04-30  9:53 ` Nicholas Piggin
2018-04-30 10:50   ` Michael Ellerman
2018-04-30 10:43 ` Michael Ellerman [this message]
2018-04-30 11:56   ` Balbir Singh

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=874ljtrn42.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=alistair@popple.id.au \
    --cc=anton@ozlabs.org \
    --cc=arbab@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=npiggin@gmail.com \
    /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