On Tue 14-03-17 20:35:21, Andrea Arcangeli wrote:
> Hello,
>
> On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote:
> > On Fri 10-03-17 13:00:37, Reza Arbab wrote:
> > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote:
> > > >OK, so whil
On Tue 14-03-17 14:20:14, Igor Mammedov wrote:
> On Mon, 13 Mar 2017 13:28:25 +0100
> Michal Hocko <mho...@kernel.org> wrote:
>
> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> > > On Thu, 9 Mar 2017 13:54:00 +0100
> > > Michal Hocko <mho...@k
On Tue 14-03-17 12:05:59, YASUAKI ISHIMATSU wrote:
>
>
> On 03/13/2017 05:19 AM, Michal Hocko wrote:
> >On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote:
> >>On 03/10/2017 08:58 AM, Michal Hocko wrote:
[...]
> >>># echo online_movable > /sys/devices/s
Let's add Andi
On Fri 10-03-17 16:53:33, Michal Hocko wrote:
> On Fri 10-03-17 14:58:07, Michal Hocko wrote:
> [...]
> > This would explain why onlining from the last block actually works but
> > to me this sounds like a completely crappy behavior. All we need to
&g
On Mon 13-03-17 14:57:12, Igor Mammedov wrote:
> On Mon, 13 Mar 2017 11:43:02 +0100
> Michal Hocko <mho...@kernel.org> wrote:
>
> > On Mon 13-03-17 11:31:10, Igor Mammedov wrote:
> > > On Fri, 10 Mar 2017 14:58:07 +0100
> > [...]
> > > > [0.
On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote:
> Michal Hocko <mho...@kernel.org> writes:
>
> > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> >> Michal Hocko <mho...@kernel.org> writes:
> >>
> >&
On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> Michal Hocko <mho...@kernel.org> writes:
>
> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> >> > >
> >> > >- suggested RFC is not acceptable from virt point of view
> >> >
On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> On Thu, 9 Mar 2017 13:54:00 +0100
> Michal Hocko <mho...@kernel.org> wrote:
>
> [...]
> > > It's major regression if you remove auto online in kernels that
> > > run on top of x86 kvm/vmware hypervisors, maki
device_add pc-dimm,id=dimm1,memdev=mem1
> You can also specify node a pc-dimm goes to with 'node' property
> if it should go to other then node 0.
>
> device_add pc-dimm,id=dimm1,memdev=mem1,node=1
thanks for the tip
> > unfortunatelly the memory didn't show up
On Fri 10-03-17 13:00:37, Reza Arbab wrote:
> On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote:
> >OK, so while I was playing with this setup some more I probably got why
> >this is done this way. All new memblocks are added to the zone Normal
> >where they are
On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote:
> On 03/10/2017 08:58 AM, Michal Hocko wrote:
[...]
> >OK so I did with -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G
> >which generated
> >[...]
> >[0.00] ACPI: SRAT: Node 0 PXM 0
On Fri 10-03-17 14:58:07, Michal Hocko wrote:
[...]
> This would explain why onlining from the last block actually works but
> to me this sounds like a completely crappy behavior. All we need to
> guarantee AFAICS is that Normal and Movable zones do not overlap. I
> believe there is
Let's CC people touching this logic. A short summary is that onlining
memory via udev is currently unusable for online_movable because blocks
are added from lower addresses while movable blocks are allowed from
last blocks. More below.
On Thu 09-03-17 13:54:00, Michal Hocko wrote:
> On Tue 07
On Tue 07-03-17 13:40:04, Igor Mammedov wrote:
> On Mon, 6 Mar 2017 15:54:17 +0100
> Michal Hocko <mho...@kernel.org> wrote:
>
> > On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
[...]
> > > in current mainline kernel it triggers following code p
On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
> On Fri, 3 Mar 2017 09:27:23 +0100
> Michal Hocko <mho...@kernel.org> wrote:
>
> > On Thu 02-03-17 18:03:15, Igor Mammedov wrote:
> > > On Thu, 2 Mar 2017 15:28:16 +0100
> > > Michal Hocko <mho...@kernel.or
On Thu 02-03-17 18:03:15, Igor Mammedov wrote:
> On Thu, 2 Mar 2017 15:28:16 +0100
> Michal Hocko <mho...@kernel.org> wrote:
>
> > On Thu 02-03-17 14:53:48, Igor Mammedov wrote:
> > [...]
> > > When trying to support memory unplug on guest side in RHE
movable? Do you expect those users to disable the option because
unless I am missing something the in kernel auto onlining only supporst
regular onlining.
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Mon 27-02-17 11:28:52, Reza Arbab wrote:
> On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote:
> >diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> >index 134a2f69c21a..a72f7f64ee26 100644
> >--- a/include/linux/memory_hotplug.h
&
you imagine any situation when somebody actually might want to have
this knob enabled? From what I understand it doesn't seem to be the
case.
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Mon 27-02-17 11:49:43, Vitaly Kuznetsov wrote:
> Michal Hocko <mho...@kernel.org> writes:
>
> > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote:
> > [...]
> >> I don't have anything new to add to the discussion happened last week
> >> but I'd like to
block. This is an issue to be solved and it is doable (IMO) with some
> pre-allocation.
you cannot preallocate for all the possible memory that can be added.
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
From: Michal Hocko <mho...@suse.com>
This knob has been added by 31bc3858ea3e ("memory-hotplug: add automatic
onlining policy for the newly added memory") mainly to cover memory
hotplug based balooning solutions currently implemented for HyperV
and Xen. Both of them want to o
aks the test "test-amd64-amd64-xl-qemut-win7-amd64" in
> the Xen Project CI system.
Ohh, I can see it now. This is not an upstream commit. This is a 3.18.37
backport which was wrong! You need the follow up fix 52c84a95dc6a
("4.1.28 Fix bad backport of 8f182270dfec "mm/swap.c: flush lru pvecs on
t "test-amd64-amd64-xl-qemut-win7-amd64" in
> the Xen Project CI system.
Could you be more specific about the regression please?
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
days
and I am not sure who is his backup. For the time being I would just
suggest doing a local revert or apply Steven's patch from
http://www.spinics.net/lists/stable/msg138760.html
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log
>
> Would it be OK to revert this patch from the stable trees?
The fix up is trivial so I believe it would be better to apply the
follow up fix
http://lkml.kernel.org/r/20160714175521.3675e...@ganda
rnel.org/r/20160714175521.3675e...@gandalf.local.home
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
27 matches
Mail list logo
