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 wrote:
>
> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> > > On Thu, 9 Mar 2017 13:54:00 +0100
> > > Michal Hocko wrote:
[...]
> > > > The kernel
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
>
On Mon 13-03-17 14:57:12, Igor Mammedov wrote:
> On Mon, 13 Mar 2017 11:43:02 +0100
> Michal Hocko wrote:
>
> > On Mon 13-03-17 11:31:10, Igor Mammedov wrote:
> > > On Fri, 10 Mar 2017 14:58:07 +0100
> > [...]
> > > > [0.00] ACPI: SRA
On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote:
> Michal Hocko writes:
>
> > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> >> Michal Hocko writes:
> >>
> >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> >> >> > >
On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> Michal Hocko 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 wrote:
>
> [...]
> > > It's major regression if you remove auto online in kernels that
> > > run on top of x86 kvm/vmware hypervisors, making API cleanups
> &
gt; (qemu) 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 me
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 acc
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 T
On Tue 07-03-17 13:40:04, Igor Mammedov wrote:
> On Mon, 6 Mar 2017 15:54:17 +0100
> Michal Hocko wrote:
>
> > On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
[...]
> > > in current mainline kernel it triggers following code path:
> > >
> > >
On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
> On Fri, 3 Mar 2017 09:27:23 +0100
> Michal Hocko wrote:
>
> > On Thu 02-03-17 18:03:15, Igor Mammedov wrote:
> > > On Thu, 2 Mar 2017 15:28:16 +0100
> > > Michal Hocko wrote:
> > >
> > &
On Thu 02-03-17 18:03:15, Igor Mammedov wrote:
> On Thu, 2 Mar 2017 15:28:16 +0100
> Michal Hocko wrote:
>
> > On Thu 02-03-17 14:53:48, Igor Mammedov wrote:
> > [...]
> > > When trying to support memory unplug on guest side in RHEL7,
> > > experience show
want to online memory
as 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
&
way.
Can 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 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 summarize
27;re able to online the newly added
> 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
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 online the memory as
-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
compound page arrival
t; > commit a2d8c514753276394d68414f563591f174ef86cb
> > Author: Lukasz Odzioba
> > Date: Fri Jun 24 14:50:01 2016 -0700
> >
> > mm/swap.c: flush lru pvecs on compound page arrival
>
> This commit breaks the test "test-amd64-amd64-xl-qemut-win7-a
veral 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
On Tue 19-07-16 10:35:09, Sebastian Gottschall wrote:
> No such Message-ID known.
Ups, sorry about that. I didn't know that the stable tree is not
archived via lkml.kernel.org. Here is the link
http://www.spinics.net/lists/stable/msg138760.html
> Am 19.07.2016 um 10:32 schrieb M
.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
ml.kernel.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
28 matches
Mail list logo
