From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: linux-mm <linux-mm@kvack.org>, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] Register bootmem pages at boot on powerpc
Date: Tue, 13 Aug 2013 07:59:34 +1000 [thread overview]
Message-ID: <1376344774.32100.185.camel@pasglop> (raw)
In-Reply-To: <520952C9.3060101@linux.vnet.ibm.com>
On Mon, 2013-08-12 at 16:25 -0500, Nathan Fontenot wrote:
> On 08/12/2013 04:13 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
> >>> Can you tell me a bit more, the above makes me nervous...
> >>
> >> Ok, I agree. that message isn't quite right.
> >>
> >> What I wanted to convey is that memory hotplug is not fully supported
> >> on powerpc with SPARSE_VMEMMAP enabled.. Perhaps the message should read
> >> "Memory hotplug is not fully supported for bootmem info nodes".
> >>
> >> Thoughts?
> >
> > Since SPARSE_VMEMMAP is our default and enabled in our distros, that mean
> > that memory hotplug isn't fully supported for us in general ?
>
> Actually... We have had the distros (at least SLES 11 and RHEL 6 releases)
> disable SPARSE_VMEMMAP in their releases.
Yuck ! That has a significant impact on performances... Additionally our
VFIO implementation for KVM requires SPARSE_VMEMMAP. Why is it that this
was never fixed in all these years ?
> >
> > What do you mean by "not fully supported" ? What precisely is missing ?
> > What will happen if one tries to plug or unplug memory?
>
> I don't know everything that is missing, but there are several routines
> that need to be defined for power to support memory hotplug with SPARSE_VMEMMAP.
>
> >
> > Shouldn't we fix it ?
>
> Working on it, but it's not there yet.
Ok, thanks.
Cheers,
Ben.
> >
> > Cheers,
> > Ben.
> >
> >
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 2/2] Register bootmem pages at boot on powerpc
Date: Tue, 13 Aug 2013 07:59:34 +1000 [thread overview]
Message-ID: <1376344774.32100.185.camel@pasglop> (raw)
In-Reply-To: <520952C9.3060101@linux.vnet.ibm.com>
On Mon, 2013-08-12 at 16:25 -0500, Nathan Fontenot wrote:
> On 08/12/2013 04:13 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
> >>> Can you tell me a bit more, the above makes me nervous...
> >>
> >> Ok, I agree. that message isn't quite right.
> >>
> >> What I wanted to convey is that memory hotplug is not fully supported
> >> on powerpc with SPARSE_VMEMMAP enabled.. Perhaps the message should read
> >> "Memory hotplug is not fully supported for bootmem info nodes".
> >>
> >> Thoughts?
> >
> > Since SPARSE_VMEMMAP is our default and enabled in our distros, that mean
> > that memory hotplug isn't fully supported for us in general ?
>
> Actually... We have had the distros (at least SLES 11 and RHEL 6 releases)
> disable SPARSE_VMEMMAP in their releases.
Yuck ! That has a significant impact on performances... Additionally our
VFIO implementation for KVM requires SPARSE_VMEMMAP. Why is it that this
was never fixed in all these years ?
> >
> > What do you mean by "not fully supported" ? What precisely is missing ?
> > What will happen if one tries to plug or unplug memory?
>
> I don't know everything that is missing, but there are several routines
> that need to be defined for power to support memory hotplug with SPARSE_VMEMMAP.
>
> >
> > Shouldn't we fix it ?
>
> Working on it, but it's not there yet.
Ok, thanks.
Cheers,
Ben.
> >
> > Cheers,
> > Ben.
> >
> >
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-08-12 21:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 15:29 [PATCH 0/2] Correct memory hotplug remove Nathan Fontenot
2013-08-09 15:30 ` [PATCH 1/2] Mark memory resources as busy Nathan Fontenot
2013-08-09 15:32 ` [PATCH 2/2] Register bootmem pages at boot on powerpc Nathan Fontenot
2013-08-09 15:32 ` Nathan Fontenot
2013-08-12 0:19 ` Benjamin Herrenschmidt
2013-08-12 0:19 ` Benjamin Herrenschmidt
2013-08-12 13:01 ` Nathan Fontenot
2013-08-12 13:01 ` Nathan Fontenot
2013-08-12 21:13 ` Benjamin Herrenschmidt
2013-08-12 21:13 ` Benjamin Herrenschmidt
2013-08-12 21:25 ` Nathan Fontenot
2013-08-12 21:25 ` Nathan Fontenot
2013-08-12 21:59 ` Benjamin Herrenschmidt [this message]
2013-08-12 21:59 ` Benjamin Herrenschmidt
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=1376344774.32100.185.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nfont@linux.vnet.ibm.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 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.