. Node 0 needed to have memory and processors. Not sure what else
> may break.
This assumption is simply incorrect. There many examples but just
one from top of my head 3e8589963773 ("memcg: make it work on sparse
non-0-node systems"). We simply have to forget that some nodes are
special.
--
Michal Hocko
SUSE Labs
able to specify also "online_movable" as well as "online_kernel"
>
> This patch series looks good, thanks. Since Andrew has merged it to -mm again,
> I won't add my Reviewed-by to bother.
JFYI, Andrew usually adds R-b or A-b tags as they are posted.
--
Michal Hocko
SUSE Labs
plan to me. The code shouldn't really care.
--
Michal Hocko
SUSE Labs
On Wed 18-03-20 16:32:15, Srikar Dronamraju wrote:
> * Michal Hocko [2020-03-18 11:02:56]:
>
> > On Wed 18-03-20 12:58:07, Srikar Dronamraju wrote:
[...]
> > > -#define node_present_pages(nid) (NODE_DATA(nid)->node_present_pages)
> > > -#define node_s
441c90] do_mkdirat+0xb0/0x1a0
> [c008b3783e20] [c000b278] system_call+0x5c/0x68
>
> Fix this by verifying the node is online before accessing the pgdat
> structure. Fix the same for node_spanned_pages() too.
>
> Cc: Andrew Morton
> Cc: linux...@kvack.org
&
On Tue 17-03-20 14:44:45, Vlastimil Babka wrote:
> On 3/16/20 10:06 AM, Michal Hocko wrote:
> > On Thu 12-03-20 17:41:58, Vlastimil Babka wrote:
> > [...]
> >> with nid present in:
> >> N_POSSIBLE - pgdat might not exist, node_to_mem_node() must return some
&g
t; - "memhp_default_state=" on the kernel cmdline
> - /sys/devices/system/memory/auto_online_blocks
> just like we are able to specify for a single memory block via
> /sys/devices/system/memory/memoryX/state
>
> Reviewed-by: Wei Yang
> Cc: Greg Kroah-Hartman
> Cc: Andrew M
On Tue 17-03-20 11:49:41, David Hildenbrand wrote:
> ... and rename it to memhp_default_online_type. This is a preparation
> for more detailed default online behavior.
>
> Reviewed-by: Wei Yang
> Cc: Greg Kroah-Hartman
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar
On Tue 17-03-20 11:49:40, David Hildenbrand wrote:
> All in-tree users except the mm-core are gone. Let's drop the export.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: "Rafael J. Wysocki"
> Cc: Baoquan He
> Cc: Wei Yang
> Sig
> Cc: Andrew Morton
> Cc: Greg Kroah-Hartman
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: "Rafael J. Wysocki"
> Cc: Baoquan He
> Cc: Wei Yang
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: David Hildenbrand
Acked-by: Michal Hocko
> ---
>
On Mon 16-03-20 16:34:06, David Hildenbrand wrote:
[...]
> Best I can do here is to also always online all memory.
Yes that sounds like a cleaner solution than having a condition that
doesn't make much sense at first glance.
--
Michal Hocko
SUSE Labs
he consumer. The userspace or the kernel could
handle the hotadd request much more easier that way.
> Cc: Greg Kroah-Hartman
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: "Rafael J. Wysocki"
> Cc: Baoquan He
> Cc: Wei Yang
> Sig
the original code is
fishy already but this just makes it even more ugly.
--
Michal Hocko
SUSE Labs
On Wed 11-03-20 13:30:24, David Hildenbrand wrote:
> Let's use a simple array which we can reuse soon. While at it, move the
> string->mmop conversion out of the device hotplug lock.
>
> Cc: Greg Kroah-Hartman
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar S
ah-Hartman
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: "Rafael J. Wysocki"
> Cc: Baoquan He
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
Acked-by: Michal Hocko
> ---
> drivers/base/memory.c | 11 ---
> include
insist on though.
> Add some documentation to the types.
>
> Cc: Greg Kroah-Hartman
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: "Rafael J. Wysocki"
> Cc: Baoquan He
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
> ---
>
eak some of the low level routines to do the
special casing but I really have to say I do not like that. We shouldn't
use the first online node or anything like that. We should simply always
follow the topology presented by FW and of that we need to have a pgdat.
--
Michal Hocko
SUSE Labs
s is
really a bad idea because it would make HW/LPAR configuration matching
to the resulting memory layout really hard to follow.
--
Michal Hocko
SUSE Labs
his somehow related to
http://lkml.kernel.org/r/20200227182650.gg3...@dhcp22.suse.cz?
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Cc: Michal Hocko
> Cc: Mel Gorman
> Cc: Vlastimil Babka
> Cc: "Kirill A. Shutemov"
On Thu 27-02-20 19:26:54, Michal Hocko wrote:
> [Cc ppc maintainers]
[...]
> Please have a look at
> http://lkml.kernel.org/r/52ef4673-7292-4c4c-b459-af583951b...@linux.vnet.ibm.com
> for the boot log with the debugging patch which tracks set_numa_mem.
> This seems to lead to a cr
eixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Signed-off-by: Logan Gunthorpe
Acked-by: Michal Hocko
> ---
> arch/x86/include/asm/page_
On Fri 21-02-20 11:24:58, Logan Gunthorpe wrote:
> The mhp_restrictions struct really doesn't specify anything resembling
> a restriction anymore so rename it to be mhp_params as it is a list
> of extended parameters.
>
> Signed-off-by: Logan Gunthorpe
Acked-by: Michal Hocko
On Fri 21-02-20 11:24:57, Logan Gunthorpe wrote:
> This variable is not used anywhere and should therefore be removed
> from the structure.
>
> Signed-off-by: Logan Gunthorpe
> Reviewed-by: David Hildenbrand
Acked-by: Michal Hocko
> ---
> include/linux/memory_hotpl
[Cc ppc maintainers]
On Thu 27-02-20 17:16:41, Vlastimil Babka wrote:
> On 2/27/20 5:00 PM, Sachin Sant wrote:
> >
> >
> >> On 27-Feb-2020, at 5:42 PM, Michal Hocko wrote:
> >>
> >> A very good hint indeed. I would do this
> >> diff --git a/
de_id()] = node;
+ pr_info("%s %d -> %d\n", __FUNCTION__, numa_node_id(), node);
+ dump_stack();
}
#endif
Btw. it would be also helpful to get
`faddr2line ___slab_alloc+0x334' from your kernel Sachin.
--
Michal Hocko
SUSE Labs
On Wed 26-02-20 22:45:52, Vlastimil Babka wrote:
> On 2/26/20 7:41 PM, Michal Hocko wrote:
> > On Wed 26-02-20 18:25:28, Cristopher Lameter wrote:
> >> On Mon, 24 Feb 2020, Michal Hocko wrote:
> >>
> >>> Hmm, nasty. Is there any reason why kmalloc_node
On Wed 26-02-20 12:31:56, David Rientjes wrote:
> On Wed, 26 Feb 2020, Michal Hocko wrote:
>
> > On Wed 26-02-20 18:44:13, Cristopher Lameter wrote:
> > > On Wed, 26 Feb 2020, Michal Hocko wrote:
> > >
> > > > Besides that kmalloc_node shou
On Wed 26-02-20 18:44:13, Cristopher Lameter wrote:
> On Wed, 26 Feb 2020, Michal Hocko wrote:
>
> > Besides that kmalloc_node shouldn't really have an implicit GFP_THISNODE
> > semantic right? At least I do not see anything like that documented
> > anywhere.
>
>
On Wed 26-02-20 18:25:28, Cristopher Lameter wrote:
> On Mon, 24 Feb 2020, Michal Hocko wrote:
>
> > Hmm, nasty. Is there any reason why kmalloc_node behaves differently
> > from the page allocator?
>
> The page allocator will do the same thing if you pass GFP_THISNODE an
On Sat 22-02-20 03:38:11, Cristopher Lameter wrote:
> On Tue, 18 Feb 2020, Michal Hocko wrote:
>
> > Anyway, I do not think it is expected that kmalloc_node just blows up
> > on those nodes. The page allocator simply falls back to the closest
> > node. Something for kmall
2 23 24
> 25 26 27 28 29 30 31
> node 1 size: 35247 MB
> node 1 free: 30907 MB
> node distances:
> node 0 1
> 0: 10 40
> 1: 40 10
> #
>
> Thanks
> -Sachin
--
Michal Hocko
SUSE Labs
On Tue 18-02-20 19:30:33, Sachin Sant wrote:
>
>
> > On 18-Feb-2020, at 5:25 PM, Michal Hocko wrote:
> >
> > On Tue 18-02-20 17:10:47, Sachin Sant wrote:
> >>
> >>>> could you please test your boot with original patch from here:
> >&
em_call+0x5c/0x68
> [8.868605] Instruction dump:
> [8.868608] 7c421378 e95f 714a0001 4082fff0 4b64 6000 6000
> faa10088
> [8.868615] 3ea2000c 3ab57070 7b4a1f24 7d55502a 2faa
> 409e0394 3d02002a
> [8.868623] ---[ end trace f9b8e3c36493f430 ]---
> [8.870690]
> [9.870701] Kernel panic - not syncing: Fatal exception
>
> Thanks
> -Sachin
--
Michal Hocko
SUSE Labs
course. Some areas have barely
anybody for a review except for the person actively writing code in that
area so this really needs the case by case approach.
Anyway this is not a new discussion or a new problem we are facing. I
believe that part of the problem is that the MM subsystem doesn't really
On Wed 22-01-20 19:46:15, David Hildenbrand wrote:
> On 22.01.20 19:38, Michal Hocko wrote:
[...]
> > How exactly is check + offline more optimal then offline which makes
> > check as its first step? I will get to your later points after this is
> > clarified.
>
>
On Wed 22-01-20 19:15:47, David Hildenbrand wrote:
[...]
> c) CC relevant people I identify (lsmem/chmem/powerpc-utils/etc.) on the
> patch to see if we are missing other use cases/users/implications.
>
> Sounds like a plan?
I would start with this step. Thanks!
--
Michal Hocko
SUSE Labs
On Wed 22-01-20 19:15:47, David Hildenbrand wrote:
> On 22.01.20 17:46, Michal Hocko wrote:
> > On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
[...]
> >> Especially interesting for IBM z Systems, whereby memory
> >> onlining/offlining will trigger the
On Wed 22-01-20 12:58:16, David Hildenbrand wrote:
> On 22.01.20 11:54, David Hildenbrand wrote:
> > On 22.01.20 11:42, Michal Hocko wrote:
> >> On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
> >>>>>> Really, the interface is f
t least powerpc-utils (why this interface was introduced) will
> notice a) performance wise and b) because more logging output will be
> generated (obviously non-offlineable blocks will be tried to offline).
I would really appreciate some specific example for a real usecase. I am
not familiar with powerpc-utils worklflows myself.
--
Michal Hocko
SUSE Labs
On Mon 20-01-20 10:14:44, David Hildenbrand wrote:
> On 20.01.20 08:48, Michal Hocko wrote:
> > On Fri 17-01-20 08:57:51, Dan Williams wrote:
> > [...]
> >> Unless the user is willing to hold the device_hotplug_lock over the
> >> evaluation then the result i
sucks...
--
Michal Hocko
SUSE Labs
On Fri 17-01-20 15:58:26, David Hildenbrand wrote:
> On 17.01.20 15:52, Michal Hocko wrote:
> > On Fri 17-01-20 14:08:06, David Hildenbrand wrote:
> >> On 17.01.20 12:33, Michal Hocko wrote:
> >>> On Fri 17-01-20 11:57:59, David Hildenbrand wrote:
> >>>&g
On Fri 17-01-20 14:08:06, David Hildenbrand wrote:
> On 17.01.20 12:33, Michal Hocko wrote:
> > On Fri 17-01-20 11:57:59, David Hildenbrand wrote:
> >> Let's refactor that code. We want to check if we can offline memory
> >> blocks. Add a new function
offline one block after another
is essentially going to achieve the same.
Or does anybody see any reasonable usecase that would break if we did
that unconditional behavior?
--
Michal Hocko
SUSE Labs
sh doesn't support ZONE_DEVICE anyway.
>
> Cc: Dan Williams
> Cc: David Hildenbrand
> Cc: Michal Hocko
> Signed-off-by: Logan Gunthorpe
OK, this is less code churn than I expected. Having pgprot as an implcit
parameter de-facto is a bit fragile though. Should we add a WARN_ON_
new use cases coming up
> for it in the future. That's more what memremap_pages() is for.
OK, fair enough. If this is indeed the simplest way forward then I will
not stand in the way.
--
Michal Hocko
SUSE Labs
On Tue 10-12-19 11:09:46, David Hildenbrand wrote:
> On 10.12.19 11:04, Michal Hocko wrote:
> > On Mon 09-12-19 12:43:40, Dan Williams wrote:
> >> On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe
> >> wrote:
> >>>
> >>>
> >&
people to think about PAGE_KERNEL or which
protection to use because my experience tells that this will get copied
without much thinking or simply will break with some odd usecases.
So how exactly this would be used?
--
Michal Hocko
SUSE Labs
On Mon 09-12-19 14:24:22, Logan Gunthorpe wrote:
>
>
> On 2019-12-09 1:41 p.m., Michal Hocko wrote:
> > On Mon 09-12-19 13:24:19, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> >>> On 09.12.19 20
espective functions
> >> which set up the page tables. For x86_32, set the page tables explicitly
> >> using _set_memory_prot() (seeing they are already mapped). For sh, reject
> >> anything but PAGE_KERNEL settings -- this should be fine, for now, seeing
> >
On Thu 14-11-19 14:19:11, David Hildenbrand wrote:
> Now that the memory isolate notifier is gone, the parameter is always 0.
> Drop it and cleanup has_unmovable_pages().
>
> Cc: Michal Hocko
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Anshuman Khandual
> Cc: Qia
On Thu 14-11-19 14:19:10, David Hildenbrand wrote:
> Luckily, we have no users left, so we can get rid of it. Cleanup
> set_migratetype_isolate() a little bit.
>
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Cc: Andrew Morton
> Cc: Pavel Tatashin
> Cc
On Wed 30-10-19 11:28:00, Peter Zijlstra wrote:
> On Wed, Oct 30, 2019 at 11:22:29AM +0100, Michal Hocko wrote:
> > On Wed 30-10-19 11:14:49, Peter Zijlstra wrote:
> > > On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
> > > > When passing t
eturn cpu_online_mask for NUMA_NO_NODE.
> >
> > Also there is a debugging version of node_to_cpumask_map() for x86 and
> > arm64, which is only used when CONFIG_DEBUG_PER_CPU_MAPS is defined, this
> > patch changes it to handle NUMA_NO_NODE as normal node_to_cpumask_map().
>
when CONFIG_DEBUG_PER_CPU_MAPS is defined, this
> patch changes it to handle NUMA_NO_NODE as normal node_to_cpumask_map().
>
> [1] https://lkml.org/lkml/2019/9/11/66
Please do not use lkml.org links. They tend to break quite often.
Use http://lkml.kernel.org/r/$msg_id or lore.kernel.o
>
> Hi, all.
>
> The warning for the above case has been added in [1].
>
> So maybe it makes sense to make node_to_cpumask_map() NUMA_NO_NODE aware
> now?
>
> If Yes, this patch still can be applied to the latest linus' tree cleanly,
> Do I need to resend it?
>
By this patch you mean
http://lkml.kernel.org/r/1568724534-146242-1-git-send-email-linyunsh...@huawei.com
right?
I would just resend it unless there is still a clear disagreement over
it.
> [1]
> https://lore.kernel.org/linux-pci/1571467543-26125-1-git-send-email-linyunsh...@huawei.com/
--
Michal Hocko
SUSE Labs
Poisoned(p))
> [ 13.898549][T1] [ cut here ]
> [ 13.898549][T1] kernel BUG at ./include/linux/mm.h:1107!
> [ 13.898549][ T1] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN PTI
> [ 13.898549][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.4.0-rc3-next-20191015+ #
--
Michal Hocko
SUSE Labs
On Tue 15-10-19 14:09:56, Michal Hocko wrote:
> On Tue 15-10-19 13:50:02, David Hildenbrand wrote:
> > On 15.10.19 13:47, Michal Hocko wrote:
> > > On Tue 15-10-19 13:42:03, David Hildenbrand wrote:
> > > [...]
> > > > > -static bo
On Tue 15-10-19 13:50:02, David Hildenbrand wrote:
> On 15.10.19 13:47, Michal Hocko wrote:
> > On Tue 15-10-19 13:42:03, David Hildenbrand wrote:
> > [...]
> > > > -static bool pfn_range_valid_gigantic(struct zone *z,
> > > > - unsigned
o_online_page() here
> instead of a pfn_valid() ?
http://lkml.kernel.org/r/20180423000943.go17...@dhcp22.suse.cz
--
Michal Hocko
SUSE Labs
at they are testing for would be
really appreciated. Who wants to run these tests and why/when? What kind
of bugs would get detected? In short why do we really need/want this
code in the tree?
--
Michal Hocko
SUSE Labs
kml.kernel.org/r/20180423000943.go17...@dhcp22.suse.cz
Order based API makes sense for the buddy allocator but why should we
restrict sizes like that for an allocator that is capable to allocate
arbitrary page sized requests?
--
Michal Hocko
SUSE Labs
de is rather error
prone. You can never assume topology. We used to assume that there
always be node 0 but that is not really the case (see 3e8589963773
("memcg: make it work on sparse non-0-node systems")). Nodes might also
come and go so this might just lead to all sorts of subtle problems.
On the other hand using NUMA_NO_NODE as no preference could only lead to
slightly sub optimal performance.
I do agree with Peter that reporting a lack of affinity might be useful
but we shouldn't really try to clever and make up the affinity nilly
willy.
--
Michal Hocko
SUSE Labs
On Wed 25-09-19 12:40:40, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 03:19:39PM +0200, Michal Hocko wrote:
>
> > > The below would get rid of the PMU and workqueue warnings with no
> > > side-effects (the device isn't used for anything except sysfs).
> >
>
On Tue 24-09-19 14:59:36, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 02:43:25PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote:
> > > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote:
> >
> > > > We ca
On Tue 24-09-19 14:09:43, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 01:54:01PM +0200, Michal Hocko wrote:
> > On Tue 24-09-19 13:23:49, Peter Zijlstra wrote:
> > > On Tue, Sep 24, 2019 at 12:56:22PM +0200, Michal Hocko wrote:
> > [...]
> > > > To be hones
On Tue 24-09-19 13:23:49, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 12:56:22PM +0200, Michal Hocko wrote:
[...]
> > To be honest I really fail to see why to object to a simple semantic
> > that NUMA_NO_NODE imply all usable cpus. Could you explain that please?
>
> B
On Tue 24-09-19 11:17:14, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 09:47:51AM +0200, Michal Hocko wrote:
> > On Mon 23-09-19 22:34:10, Peter Zijlstra wrote:
> > > On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote:
> > [...]
> > > > I even the
On Mon 23-09-19 22:34:10, Peter Zijlstra wrote:
> On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote:
[...]
> > I even the
> > ACPI standard is considering this optional. Yunsheng Lin has referred to
> > the specific part of the standard in one of the earlier di
On Mon 23-09-19 17:48:52, Peter Zijlstra wrote:
> On Mon, Sep 23, 2019 at 05:28:56PM +0200, Michal Hocko wrote:
> > On Mon 23-09-19 17:15:19, Peter Zijlstra wrote:
>
> > > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > > > index 4123100e..9859
itty browser software.
>
> (also patchwork is absolute crap for reading email threads)
>
> Anyway, I found it -- I think, I refused to click the link. I replied
> there.
>
> > Signed-off-by: Yunsheng Lin
> > Suggested-by: Michal Hocko
> > Acked-by: Michal Hocko
>
On Tue 17-09-19 17:53:57, Yunsheng Lin wrote:
> On 2019/9/17 17:36, Michal Hocko wrote:
> > On Tue 17-09-19 14:20:11, Yunsheng Lin wrote:
> >> On 2019/9/17 13:28, Michael Ellerman wrote:
> >>> Yunsheng Lin writes:
> > [...]
> >>>> But we cannot r
gt; Even if some of the arches do support CPU hotplug, it does not make sense
> to return the cpu that has been hotplugged.
>
> Any suggestion?
Again, for the third time, I believe. Make it a separate patch please.
There is absolutely no reason to conflate those two things.
--
Michal Hocko
SUSE Labs
"cpumask_of_node(%d): node >= nr_node_ids(%u)\n",
> >>node, nr_node_ids);
> >>dump_stack();
> >>return cpu_none_mask;
> >
> > Why do we need this?
>
> As the commit log says, the above cpumask_of_node() is for debugging,
> it should catch other "node < 0" cases except NUMA_NO_NODE.
OK, I would just make it a separate patch.
--
Michal Hocko
SUSE Labs
t;fix" a sign "bug" since it is for debugging and should catch all the
> error cases.
>
> [1] https://lore.kernel.org/patchwork/patch/1125789/
> Signed-off-by: Yunsheng Lin
> Suggested-by: Michal Hocko
The change makes sense to me. I wish this particular thing wasn't
dup
On Tue 27-08-19 16:39:56, Alastair D'Silva wrote:
> On Tue, 2019-08-27 at 08:28 +0200, Michal Hocko wrote:
> > On Tue 27-08-19 15:20:46, Alastair D'Silva wrote:
> > > From: Alastair D'Silva
> > >
> > > It is possible for firmware to allocate memory ranges
int rc;
>
> + if ((start + size - 1) >> MAX_PHYSMEM_BITS)
> + return -EINVAL;
> +
> resize_hpt_for_hotplug(memblock_phys_mem_size());
>
> start = (unsigned long)__va(start);
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
> On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:
> > On Wed 31-07-19 15:26:32, Mike Rapoport wrote:
> > > On Wed, Jul 31, 2019 at 01:40:16PM +0200, Michal Hocko wrote:
> > > > On Wed 31-07-19
On Wed 31-07-19 15:26:32, Mike Rapoport wrote:
> On Wed, Jul 31, 2019 at 01:40:16PM +0200, Michal Hocko wrote:
> > On Wed 31-07-19 14:14:22, Mike Rapoport wrote:
> > > On Wed, Jul 31, 2019 at 10:03:09AM +0200, Michal Hocko wrote:
> > > > On Wed 31-07-19
On Wed 31-07-19 14:14:22, Mike Rapoport wrote:
> On Wed, Jul 31, 2019 at 10:03:09AM +0200, Michal Hocko wrote:
> > On Wed 31-07-19 09:24:21, Mike Rapoport wrote:
> > > [ sorry for a late reply too, somehow I missed this thread before ]
> > >
> > > On Tue, Jul
On Wed 31-07-19 09:24:21, Mike Rapoport wrote:
> [ sorry for a late reply too, somehow I missed this thread before ]
>
> On Tue, Jul 30, 2019 at 10:14:15AM +0200, Michal Hocko wrote:
> > [Sorry for a late reply]
> >
> > On Mon 15-07-19 17:55:07, Hoan Tran OS wrote:
>
[Sorry for a late reply]
On Mon 15-07-19 17:55:07, Hoan Tran OS wrote:
> Hi,
>
> On 7/12/19 10:00 PM, Michal Hocko wrote:
[...]
> > Hmm, I thought this was selectable. But I am obviously wrong here.
> > Looking more closely, it seems that this is indeed only about
&
On Mon 15-07-19 12:51:27, David Hildenbrand wrote:
> On 01.07.19 14:46, Michal Hocko wrote:
> > On Mon 01-07-19 09:43:06, Michal Hocko wrote:
> >> On Mon 27-05-19 13:11:43, David Hildenbrand wrote:
> >>> ZONE_DEVICE is not yet supported, fail if an altmap is pa
impler rather than going half way
to get there. I would have liked the above for the purpose of this patch
more and then go with another one to remove the config altogether. But
Andrew has already sent his patch bomb including this series to Linus so
this is all moot.
--
Michal Hocko
SUSE Labs
On Mon 15-07-19 13:10:33, David Hildenbrand wrote:
> On 01.07.19 12:27, Michal Hocko wrote:
> > On Mon 01-07-19 11:36:44, Oscar Salvador wrote:
> >> On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
> >>> Yeah, we do not allow to offline multi zon
On Fri 12-07-19 15:37:30, Will Deacon wrote:
> Hi all,
>
> On Fri, Jul 12, 2019 at 02:12:23PM +0200, Michal Hocko wrote:
> > On Fri 12-07-19 10:56:47, Hoan Tran OS wrote:
> > [...]
> > > It would be good if we can enable it by-default. Otherwise, let arch
> &g
option in the first place. Please explain
what motivated you to make this change.
--
Michal Hocko
SUSE Labs
PAN_OTHER_NODES by default for NUMA to fix this issue.
Yes it can occur on any arch but most sane platforms simply do not
overlap physical ranges. So I do not really see any reason to
unconditionally enable the config for everybody. What is an advantage?
--
Michal Hocko
SUSE Labs
On Mon 01-07-19 10:01:41, Michal Hocko wrote:
> On Mon 27-05-19 13:11:47, David Hildenbrand wrote:
> > We want to improve error handling while adding memory by allowing
> > to use arch_remove_memory() and __remove_pages() even if
> > CONFIG_MEMORY_HOTREMOVE is not set to e.g.
page tables (also in arch_add_memory() in case
> + * adding fails). Until then, this function should only be used
> + * during memory hotplug (adding memory), not for memory
> + * unplug. ARCH_ENABLE_MEMORY_HOTREMOVE must not be
> + * unlocked yet.
> + */
> + zone = page_zone(pfn_to_page(start_pfn));
> + __remove_pages(zone, start_pfn, nr_pages, altmap);
> +}
> +#endif
> #endif
> --
> 2.20.1
--
Michal Hocko
SUSE Labs
On Mon 01-07-19 09:45:03, Michal Hocko wrote:
> On Mon 27-05-19 13:11:44, David Hildenbrand wrote:
> > Will come in handy when wanting to handle errors after
> > arch_add_memory().
>
> I do not understand this. Why do you add a code for something that is
> not po
On Mon 01-07-19 09:43:06, Michal Hocko wrote:
> On Mon 27-05-19 13:11:43, David Hildenbrand wrote:
> > ZONE_DEVICE is not yet supported, fail if an altmap is passed, so we
> > don't forget arch_add_memory()/arch_remove_memory() when unlocking
> > support.
>
> Why do we
On Mon 01-07-19 11:36:44, Oscar Salvador wrote:
> On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
> > Yeah, we do not allow to offline multi zone (node) ranges so the current
> > code seems to be over engineered.
> >
> > Anyway, I am wondering why d
ildenbrand
Acked-by: Michal Hocko
> ---
> include/linux/memory_hotplug.h | 2 +-
> mm/memory_hotplug.c| 2 +-
> mm/sparse.c| 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/memory_hotplug.h b
nbrand
> Cc: Oscar Salvador
> Cc: Andrew Morton
> Cc: Jonathan Cameron
> Signed-off-by: David Hildenbrand
Anyway
Acked-by: Michal Hocko
> ---
> drivers/base/node.c | 18 +-
> include/linux/node.h | 5 ++---
> 2 files changed, 7 insertions(+), 16
a...@hpe.com"
> Cc: Andrew Morton
> Cc: Andrew Banman
> Cc: Ingo Molnar
> Cc: Alex Deucher
> Cc: "David S. Miller"
> Cc: Mark Brown
> Cc: Chris Wilson
> Cc: Oscar Salvador
> Cc: Jonathan Cameron
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc
On Mon 27-05-19 13:11:49, David Hildenbrand wrote:
> No longer needed, the callers of arch_add_memory() can handle this
> manually.
>
> Cc: Andrew Morton
> Cc: David Hildenbrand
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Cc: Wei Yang
> C
ind_memory_block_by_id() in init_memory_block() to catch
> duplicates
>
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Cc: David Hildenbrand
> Cc: "mike.tra...@hpe.com"
> Cc: Andrew Morton
> Cc: Ingo Molnar
> Cc: Andrew Banman
> Cc:
inori Sato
> Cc: Rich Felker
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Cc: And
On Mon 27-05-19 13:11:46, David Hildenbrand wrote:
> We'll rework hotplug_memory_register() shortly, so it no longer consumes
> pass a section.
>
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Signed-off-by: David Hildenbrand
Acked-by: Michal Hocko
> --
101 - 200 of 482 matches
Mail list logo
