On Fri, Nov 24, 2017 at 02:29:48PM +, Andrea Reale wrote:
But, at least in my understanding, the implementation is not as
straightfoward as it looks. If I declare a memory node in the fdt, then,
at boot, the kernel will expect that memory to actually be there to be
used: this is not true if I
On Mon 4 Dec 2017, 13:33, Michal Hocko wrote:
> On Mon 04-12-17 11:51:29, Andrea Reale wrote:
> > On Thu 30 Nov 2017, 15:49, Michal Hocko wrote:
> > > On Thu 23-11-17 11:14:52, Andrea Reale wrote:
> > > > Adding a "remove" sysfs handle that can be used to trigger
> > > > memory hotremove manually,
On Mon 04-12-17 11:51:29, Andrea Reale wrote:
> On Thu 30 Nov 2017, 15:49, Michal Hocko wrote:
> > On Thu 23-11-17 11:14:52, Andrea Reale wrote:
> > > Adding a "remove" sysfs handle that can be used to trigger
> > > memory hotremove manually, exactly simmetrically with
> > > what happens with the "
On Thu 30 Nov 2017, 15:49, Michal Hocko wrote:
> On Thu 23-11-17 11:14:52, Andrea Reale wrote:
> > Adding a "remove" sysfs handle that can be used to trigger
> > memory hotremove manually, exactly simmetrically with
> > what happens with the "probe" device for hot-add.
> >
> > This is usueful for
On Thu 23-11-17 11:14:52, Andrea Reale wrote:
> Adding a "remove" sysfs handle that can be used to trigger
> memory hotremove manually, exactly simmetrically with
> what happens with the "probe" device for hot-add.
>
> This is usueful for architecture that do not rely on
> ACPI for memory hot-remo
Hi Robin,
On Mon 27 Nov 2017, 15:33, Robin Murphy wrote:
> On 23/11/17 11:14, Andrea Reale wrote:
> >Adding a "remove" sysfs handle that can be used to trigger
> >memory hotremove manually, exactly simmetrically with
> >what happens with the "probe" device for hot-add.
> >
> >This is usueful for a
On 23/11/17 11:14, Andrea Reale wrote:
Adding a "remove" sysfs handle that can be used to trigger
memory hotremove manually, exactly simmetrically with
what happens with the "probe" device for hot-add.
This is usueful for architecture that do not rely on
ACPI for memory hot-remove.
Is there a
Hi zhongjian,
On Fri 24 Nov 2017, 20:17, zhong jiang wrote:
> Hi, Andrea
>
> most of server will benefit from NUMA ,it is best to sovle the issue without
> spcial restrictions.
>
> At least we can obtain the numa information from dtb. therefore, The memory
> can
> online correctly.
I fully agr
Hi, Andrea
most of server will benefit from NUMA ,it is best to sovle the issue without
spcial restrictions.
At least we can obtain the numa information from dtb. therefore, The memory can
online correctly.
Thanks
zhongjiang
On 2017/11/24 18:44, Andrea Reale wrote:
> Hi zhongjiang,
>
> On Fri 2
Hi zhongjiang,
On Fri 24 Nov 2017, 18:35, zhong jiang wrote:
> HI, Andrea
>
> I don't see "memory_add_physaddr_to_nid" in arch/arm64.
> Am I miss something?
When !CONFIG_NUMA it is defined in include/linux/memory_hotplug.h as 0.
In patch 1/5 of this series we require !NUMA to enable
ARCH_ENABLE_
HI, Andrea
I don't see "memory_add_physaddr_to_nid" in arch/arm64.
Am I miss something?
Thnaks
zhongjiang
On 2017/11/23 19:14, Andrea Reale wrote:
> Adding a "remove" sysfs handle that can be used to trigger
> memory hotremove manually, exactly simmetrically with
> what happens with the "probe"
Adding a "remove" sysfs handle that can be used to trigger
memory hotremove manually, exactly simmetrically with
what happens with the "probe" device for hot-add.
This is usueful for architecture that do not rely on
ACPI for memory hot-remove.
Signed-off-by: Andrea Reale
Signed-off-by: Maciej Bi
12 matches
Mail list logo
