Re: [PATCH 1/2] x86, numa: always initialize all possible nodes

2019-05-02 Thread Michal Hocko
elpful. I will think about this some more but I am traveling this week. It seems really awkward to register a sysfs file for an empty range. That looks like a bug to me. -- Michal Hocko SUSE Labs

Re: [PATCH v12 00/31] Speculative page faults

2019-04-23 Thread Michal Hocko
On Tue 23-04-19 05:41:48, Matthew Wilcox wrote: > On Tue, Apr 23, 2019 at 12:47:07PM +0200, Michal Hocko wrote: > > On Mon 22-04-19 14:29:16, Michel Lespinasse wrote: > > [...] > > > I want to add a note about mmap_sem. In the past there has been > >

Re: [PATCH v12 00/31] Speculative page faults

2019-04-23 Thread Michal Hocko
am not opposed to this change I just think it is a large hammer while we haven't seen attempts to tackle problems in a simpler way. -- Michal Hocko SUSE Labs

Re: [PATCH 0/2] x86, numa: always initialize all possible nodes

2019-04-16 Thread Michal Hocko
Forgot to cc Andrew. Now for real. Andrew please note that Dave has reviewed the patch http://lkml.kernel.org/r/77b364e5-a30c-964a-6985-00b759dac...@intel.com Or do you want me to resubmit? On Mon 15-04-19 13:42:09, Michal Hocko wrote: > On Tue 26-02-19 14:12:01, Michal Hocko wrote: > &g

Re: [PATCH 0/2] x86, numa: always initialize all possible nodes

2019-04-15 Thread Michal Hocko
On Tue 26-02-19 14:12:01, Michal Hocko wrote: > On Tue 12-02-19 10:53:41, Michal Hocko wrote: > > Hi, > > this has been posted as an RFC previously [1]. There didn't seem to be > > any objections so I am reposting this for inclusion. I have added a > > debugging patc

Re: [PATCH v8 1/4] mm/cma: Add PF flag to force non cma alloc

2019-02-28 Thread Michal Hocko
get separate variable > for gfp context at this point? Yes, that sounds like a reasonable thing to do. Just note that xfs still uses current_{set,restore}* api to handle PF_MEMALLOC_NOFS so that would have to be moved over to the memalloc_nofs_{save,restore} API. -- Michal Hocko

Re: [PATCH 0/2] x86, numa: always initialize all possible nodes

2019-02-26 Thread Michal Hocko
On Tue 12-02-19 10:53:41, Michal Hocko wrote: > Hi, > this has been posted as an RFC previously [1]. There didn't seem to be > any objections so I am reposting this for inclusion. I have added a > debugging patch which prints the zonelist setup for each numa node > for an e

Re: [PATCH v3 2/2] mm: be more verbose about zonelist initialization

2019-02-13 Thread Michal Hocko
On Wed 13-02-19 08:14:50, Dave Hansen wrote: > On 2/13/19 1:43 AM, Michal Hocko wrote: > > > > We have seen several bugs where zonelists have not been initialized > > properly and it is not really straightforward to track those bugs down. > > One way to help a bit at

Re: [PATCH v3 2/2] mm: be more verbose about zonelist initialization

2019-02-13 Thread Michal Hocko
On Wed 13-02-19 14:11:31, Peter Zijlstra wrote: > On Wed, Feb 13, 2019 at 12:50:14PM +0100, Michal Hocko wrote: > > On Wed 13-02-19 11:32:31, Peter Zijlstra wrote: > > > On Wed, Feb 13, 2019 at 10:43:15AM +0100, Michal Hocko wrote: > > > > @@ -5259,6 +5261,11

Re: [PATCH v3 2/2] mm: be more verbose about zonelist initialization

2019-02-13 Thread Michal Hocko
On Wed 13-02-19 11:32:31, Peter Zijlstra wrote: > On Wed, Feb 13, 2019 at 10:43:15AM +0100, Michal Hocko wrote: > > @@ -5259,6 +5261,11 @@ static void build_zonelists(pg_data_t *pgdat) > > > > build_zonelists_in_node_order(pgdat, node_order, nr_nodes); > > bui

[PATCH v3 2/2] mm: be more verbose about zonelist initialization

2019-02-13 Thread Michal Hocko
From: Michal Hocko We have seen several bugs where zonelists have not been initialized properly and it is not really straightforward to track those bugs down. One way to help a bit at least is to dump zonelists of each node when they are (re)initialized. Signed-off-by: Michal Hocko --- Sorry

[PATCH v2 2/2] mm: be more verbose about zonelist initialization

2019-02-13 Thread Michal Hocko
From: Michal Hocko We have seen several bugs where zonelists have not been initialized properly and it is not really straightforward to track those bugs down. One way to help a bit at least is to dump zonelists of each node when they are (re)initialized. Signed-off-by: Michal Hocko --- mm

[PATCH 2/2] mm: be more verbose about zonelist initialization

2019-02-12 Thread Michal Hocko
From: Michal Hocko We have seen several bugs where zonelists have not been initialized properly and it is not really straightforward to track those bugs down. One way to help a bit at least is to dump zonelists of each node when they are (re)initialized. Signed-off-by: Michal Hocko --- mm

[PATCH 1/2] x86, numa: always initialize all possible nodes

2019-02-12 Thread Michal Hocko
From: Michal Hocko Pingfan Liu has reported the following splat [5.772742] BUG: unable to handle kernel paging request at 2088 [5.773618] PGD 0 P4D 0 [5.773618] Oops: [#1] SMP NOPTI [5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3 [5.773618

[PATCH 0/2] x86, numa: always initialize all possible nodes

2019-02-12 Thread Michal Hocko
Hi, this has been posted as an RFC previously [1]. There didn't seem to be any objections so I am reposting this for inclusion. I have added a debugging patch which prints the zonelist setup for each numa node for an easier debugging of a broken zonelist setup. [1]

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

2019-02-11 Thread Michal Hocko
On Mon 11-02-19 14:49:09, Ingo Molnar wrote: > > * Michal Hocko wrote: > > > On Thu 24-01-19 11:10:50, Dave Hansen wrote: > > > On 1/24/19 6:17 AM, Michal Hocko wrote: > > > > and nr_cpus set to 4. The underlying reason is tha the device is bound > > &

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

2019-01-25 Thread Michal Hocko
On Thu 24-01-19 11:10:50, Dave Hansen wrote: > On 1/24/19 6:17 AM, Michal Hocko wrote: > > and nr_cpus set to 4. The underlying reason is tha the device is bound > > to node 2 which doesn't have any memory and init_cpu_to_node only > > initializes memory-less nodes for possib

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

2019-01-25 Thread Michal Hocko
On Thu 24-01-19 19:51:44, Mike Rapoport wrote: > On Thu, Jan 24, 2019 at 03:17:27PM +0100, Michal Hocko wrote: > > a friendly ping for this. Does anybody see any problem with this > > approach? > > FWIW, it looks fine to me. > > It'd just be nice to have a few more w

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

2019-01-24 Thread Michal Hocko
a friendly ping for this. Does anybody see any problem with this approach? On Mon 14-01-19 09:24:16, Michal Hocko wrote: > From: Michal Hocko > > Pingfan Liu has reported the following splat > [5.772742] BUG: unable to handle kernel paging request at 2088 > [

Re: [PATCH V2] mm: Introduce GFP_PGTABLE

2019-01-16 Thread Michal Hocko
On Wed 16-01-19 18:57:13, Anshuman Khandual wrote: > > > On 01/16/2019 06:14 PM, Michal Hocko wrote: > > On Wed 16-01-19 04:30:18, Matthew Wilcox wrote: > >> On Wed, Jan 16, 2019 at 07:57:03AM +0100, Michal Hocko wrote: > >>> On Wed 16-01-19 11:51:32,

Re: [PATCH V2] mm: Introduce GFP_PGTABLE

2019-01-16 Thread Michal Hocko
On Wed 16-01-19 05:18:27, Matthew Wilcox wrote: > On Wed, Jan 16, 2019 at 06:42:22PM +0530, Anshuman Khandual wrote: > > On 01/16/2019 06:00 PM, Matthew Wilcox wrote: > > > On Wed, Jan 16, 2019 at 07:57:03AM +0100, Michal Hocko wrote: > > >> On Wed 16-01-19 11:

Re: [PATCH V2] mm: Introduce GFP_PGTABLE

2019-01-16 Thread Michal Hocko
On Wed 16-01-19 04:30:18, Matthew Wilcox wrote: > On Wed, Jan 16, 2019 at 07:57:03AM +0100, Michal Hocko wrote: > > On Wed 16-01-19 11:51:32, Anshuman Khandual wrote: > > > All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL > > > |

Re: [PATCH V2] mm: Introduce GFP_PGTABLE

2019-01-15 Thread Michal Hocko
void _pgd_free(pgd_t *pgd) > > static inline pgd_t *_pgd_alloc(void) > { > - return (pgd_t *)__get_free_pages(PGALLOC_GFP, PGD_ALLOCATION_ORDER); > + return (pgd_t *)__get_free_pages(GFP_PGTABLE | __GFP_ACCOUNT, > + PGD_ALLOCATION_ORDER); > } > > static inline void _pgd_free(pgd_t *pgd) > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index 05e61e6..3d9cde6 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -1186,4 +1186,6 @@ static inline bool arch_has_pfn_modify_check(void) > #define mm_pmd_folded(mm)__is_defined(__PAGETABLE_PMD_FOLDED) > #endif > > +#define GFP_PGTABLE (GFP_KERNEL | __GFP_ZERO) > + > #endif /* _ASM_GENERIC_PGTABLE_H */ > diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c > index fbdf3ac..f60a5b8 100644 > --- a/virt/kvm/arm/mmu.c > +++ b/virt/kvm/arm/mmu.c > @@ -143,7 +143,7 @@ static int mmu_topup_memory_cache(struct > kvm_mmu_memory_cache *cache, > if (cache->nobjs >= min) > return 0; > while (cache->nobjs < max) { > - page = (void *)__get_free_page(PGALLOC_GFP); > + page = (void *)__get_free_page(GFP_PGTABLE); > if (!page) > return -ENOMEM; > cache->objects[cache->nobjs++] = page; > -- > 2.7.4 > -- Michal Hocko SUSE Labs

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

2019-01-14 Thread Michal Hocko
On Mon 14-01-19 21:26:39, Michael Ellerman wrote: > Michal Hocko writes: > > > From: Michal Hocko > > > > Pingfan Liu has reported the following splat > > [5.772742] BUG: unable to handle kernel paging request at > > 2088 > > [5.7

[RFC PATCH] x86, numa: always initialize all possible nodes

2019-01-14 Thread Michal Hocko
From: Michal Hocko Pingfan Liu has reported the following splat [5.772742] BUG: unable to handle kernel paging request at 2088 [5.773618] PGD 0 P4D 0 [5.773618] Oops: [#1] SMP NOPTI [5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3 [5.773618

Re: [PATCH] mm: Introduce GFP_PGTABLE

2019-01-13 Thread Michal Hocko
On Mon 14-01-19 09:30:55, Anshuman Khandual wrote: > > > On 01/13/2019 11:05 PM, Michal Hocko wrote: > > On Sat 12-01-19 15:56:38, Anshuman Khandual wrote: > >> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL | > >> __GFP_ZERO) and u

Re: [PATCH] mm: Introduce GFP_PGTABLE

2019-01-13 Thread Michal Hocko
expose in generic gfp.h IMHO. It just risks an abuse. I would be looking at providing asm-generic implementation and reuse it to remove the code duplication. But I haven't tried that to know that it will work out due to small/subtle differences between arches. > Signed-off-by: Anshuman Khandual

Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types

2018-12-20 Thread Michal Hocko
am doing it just like > > the other types (e.g. online_type) we are using in that context. > > - The "removable" property should never have been named like that. It > > should have been "offlinable". Can we still rename that? E.g. boot memory > > is sometimes marked as removable ... > > > > > Any feedback regarding the suggested block types would be very much > appreciated! I still do not like this much to be honest. I just didn't get to think through this properly. My fear is that this is conflating an actual API with the current implementation and as such will cause problems in future. But I haven't really looked into your patches closely so I might be wrong. Anyway I won't be able to look into it by the end of year. -- Michal Hocko SUSE Labs

Re: [PATCHv2 2/3] mm/numa: build zonelist when alloc for device on offline node

2018-12-20 Thread Michal Hocko
On Thu 20-12-18 20:26:28, Pingfan Liu wrote: > On Thu, Dec 20, 2018 at 7:35 PM Michal Hocko wrote: > > > > On Thu 20-12-18 17:50:38, Pingfan Liu wrote: > > [...] > > > @@ -453,7 +456,12 @@ static inline int gfp_zonelist(gfp_t flags) > > > */ > > &g

Re: [PATCHv2 2/3] mm/numa: build zonelist when alloc for device on offline node

2018-12-20 Thread Michal Hocko
gfp_zonelist(flags); > } No, please don't do this. We do not want to make things work magically and we definitely do not want to put something like that into the hot path. We definitely need zonelists to be build transparently for all possible nodes during the init time. -- Michal Hocko SUSE Labs

Re: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region

2018-12-18 Thread Michal Hocko
for migrating compound pages. The first path adds > > the helper > > get_user_pages_cma_migrate() which pin the page making sure we migrate them > > out of > > CMA region before incrementing the reference count. > > Very little review activity. Perhaps Andrey and/or Michal can find the > time.. I will unlikely find some time before the end of the year. Sorry about that. -- Michal Hocko SUSE Labs

Re: [PATCH RFC 7/7] mm: better document PG_reserved

2018-12-05 Thread Michal Hocko
hat is independent from > PG_reserved. > > Cc: Andrew Morton > Cc: Stephen Rothwell > Cc: Pavel Tatashin > Cc: Michal Hocko > Cc: Alexander Duyck > Cc: Matthew Wilcox > Cc: Anthony Yznaga > Cc: Miles Chen > Cc: yi.z.zh...@linux.intel.com > Cc: Dan Will

Re: [PATCH RFC 0/7] mm: PG_reserved cleanups and documentation

2018-12-05 Thread Michal Hocko
served users before we can do so for device memory? I am all for removing relicts because they just confuse people but I fail to see any relation here. -- Michal Hocko SUSE Labs

Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.

2018-10-23 Thread Michal Hocko
s hard to review manually. -- Michal Hocko SUSE Labs

Re: [PATCH] memblock: stop using implicit alignement to SMP_CACHE_BYTES

2018-10-10 Thread Michal Hocko
; + memblock_alloc_low_nopanic(size, SMP_CACHE_BYTES) > | > - memblock_alloc_from_nopanic(size, 0, min_addr) > + memblock_alloc_from_nopanic(size, SMP_CACHE_BYTES, min_addr) > | > - memblock_alloc_node(size, 0, nid) > + memblock_alloc_node(size, SMP_CACHE_BYTES, nid) > ) > > Suggested-

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-04 Thread Michal Hocko
enable them anyway (e.g. RAS would require to have movable_node kernel parameters, ballooning a kernel module etc.). Really, one udev script to rule them all will simply never work. -- Michal Hocko SUSE Labs

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-04 Thread Michal Hocko
ormal and off node is not great. Especially the second part which is noticeable for whole node hotplug. I have a feeling that arguing about fork not able to proceed or OOMing for the memory hotplug is a bit of a stretch and a sign a of misconfiguration. -- Michal Hocko SUSE Labs

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
end of days here trying to come up with > an onlining solution which would work for everyone and eBPF would move > this decision to distro level. The point is that there is _no_ general onlining solution. This is basically policy which belongs to the userspace. -- Michal Hocko SUSE Labs

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
On Tue 02-10-18 17:25:19, David Hildenbrand wrote: > On 02/10/2018 15:47, Michal Hocko wrote: [...] > > Zone imbalance is an inherent problem of the highmem zone. It is > > essentially the highmem zone we all loved so much back in 32b days. > > Yes the movable zone doesn'

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Michal Hocko
On Wed 03-10-18 15:38:04, Vitaly Kuznetsov wrote: > David Hildenbrand writes: > > > On 02/10/2018 15:47, Michal Hocko wrote: > ... > >> > >> Why do you need a generic hotplug rule in the first place? Why don't you > >> simply provide different set

Re: [PATCH] migration/mm: Add WARN_ON to try_offline_node

2018-10-03 Thread Michal Hocko
On Tue 02-10-18 12:45:50, Tyrel Datwyler wrote: > On 10/02/2018 11:13 AM, Michael Bringmann wrote: > > > > > > On 10/02/2018 11:04 AM, Michal Hocko wrote: > >> On Tue 02-10-18 10:14:49, Michael Bringmann wrote: > >>> On 10/02/2018 09:59 AM, Michal Ho

Re: [PATCH] migration/mm: Add WARN_ON to try_offline_node

2018-10-02 Thread Michal Hocko
On Tue 02-10-18 10:14:49, Michael Bringmann wrote: > On 10/02/2018 09:59 AM, Michal Hocko wrote: > > On Tue 02-10-18 09:51:40, Michael Bringmann wrote: > > [...] > >> When the device-tree affinity attributes have changed for memory, > >> the 'nid' affinity calc

Re: [PATCH] migration/mm: Add WARN_ON to try_offline_node

2018-10-02 Thread Michal Hocko
ut it is not there > yet, and won't be present in earlier kernels without backporting a > significant number of changes. Then the patch you have proposed here just papers over a real issue, no? IIUC then you simply do not remove the memory if you lose the race. -- Michal Hocko SUSE Labs

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-02 Thread Michal Hocko
On Mon 01-10-18 11:34:25, David Hildenbrand wrote: > On 01/10/2018 10:40, Michal Hocko wrote: > > On Fri 28-09-18 17:03:57, David Hildenbrand wrote: > > [...] > > > > I haven't read the patch itself but I just wanted to note one thing > > about this part >

Re: [PATCH] migration/mm: Add WARN_ON to try_offline_node

2018-10-01 Thread Michal Hocko
simply backs off silently. Why don't we have to care about memblock resp dlpar_remove_device_tree_lmb parts? In other words how come the physical memory range is valid while the node association is not? -- Michal Hocko SUSE Labs

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-01 Thread Michal Hocko
ou said that distributions have hard time to distinguish different types of onlinining policies but isn't this something that is inherently usecase specific? -- Michal Hocko SUSE Labs

Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()

2018-09-26 Thread Michal Hocko
On Wed 26-09-18 16:43:35, Mike Rapoport wrote: > On Wed, Sep 26, 2018 at 11:36:48AM +0200, Michal Hocko wrote: > > On Wed 26-09-18 11:31:27, Michal Hocko wrote: > > > On Fri 14-09-18 15:10:29, Mike Rapoport wrote: > > > > With the align parameter memblock_al

Re: [PATCH 00/30] mm: remove bootmem allocator

2018-09-26 Thread Michal Hocko
my acks from the previous iteration and there are only minor comments. This looks good overall. Nice work Mike! -- Michal Hocko SUSE Labs

Re: [PATCH 29/30] mm: remove include/linux/bootmem.h

2018-09-26 Thread Michal Hocko
l of duplicated '#include > > @@ > @@ > - #include > + #include > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs

Re: [PATCH 21/30] memblock: replace alloc_bootmem with memblock_alloc

2018-09-26 Thread Michal Hocko
> diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c > index e8ae2e5..332fcca 100644 > --- a/drivers/macintosh/smu.c > +++ b/drivers/macintosh/smu.c > @@ -493,7 +493,7 @@ int __init smu_init (void) > goto fail_np; > } > > - smu = alloc_bootmem(sizeof(struct smu_device)); > + smu = memblock_alloc(sizeof(struct smu_device), 0); > > spin_lock_init(>lock); > INIT_LIST_HEAD(>cmd_list); > diff --git a/init/main.c b/init/main.c > index d0b92bd..99a9e99 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -768,8 +768,8 @@ static int __init initcall_blacklist(char *str) > str_entry = strsep(, ","); > if (str_entry) { > pr_debug("blacklisting initcall %s\n", str_entry); > - entry = alloc_bootmem(sizeof(*entry)); > - entry->buf = alloc_bootmem(strlen(str_entry) + 1); > + entry = memblock_alloc(sizeof(*entry), 0); > + entry->buf = memblock_alloc(strlen(str_entry) + 1, 0); > strcpy(entry->buf, str_entry); > list_add(>next, _initcalls); > } > -- > 2.7.4 > -- Michal Hocko SUSE Labs

Re: [PATCH 16/30] memblock: replace __alloc_bootmem_node with appropriate memblock_ API

2018-09-26 Thread Michal Hocko
On Fri 14-09-18 15:10:31, Mike Rapoport wrote: > Use memblock_alloc_try_nid whenever goal (i.e. minimal address is > specified) and memblock_alloc_node otherwise. > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs

Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()

2018-09-26 Thread Michal Hocko
On Wed 26-09-18 11:31:27, Michal Hocko wrote: > On Fri 14-09-18 15:10:29, Mike Rapoport wrote: > > With the align parameter memblock_alloc_node() can be used as drop in > > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(), > > which is done in the follow

Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()

2018-09-26 Thread Michal Hocko
if (slab_is_available()) > section = kzalloc_node(array_size, GFP_KERNEL, nid); > else > - section = memblock_alloc_node(array_size, nid); > + section = memblock_alloc_node(array_size, 0, nid); > > return section; > } > -- > 2.7.4 > -- Michal Hocko SUSE Labs

Re: [PATCH 07/30] memblock: remove _virt from APIs returning virtual address

2018-09-26 Thread Michal Hocko
It is unnecessary churn. So if nothing else just add a note _why_ you think this is better. -- Michal Hocko SUSE Labs

Re: [PATCH 05/30] mm: nobootmem: remove dead code

2018-09-26 Thread Michal Hocko
On Fri 14-09-18 15:10:20, Mike Rapoport wrote: > Several bootmem functions and macros are not used. Remove them. > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs

Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK

2018-09-26 Thread Michal Hocko
hat Acked-by: Michal Hocko -- Michal Hocko SUSE Labs

Re: [PATCH 02/30] mm: remove CONFIG_NO_BOOTMEM

2018-09-26 Thread Michal Hocko
e seen a patch to address that. It would be great to have it folded to this one. > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs

Re: [RFC PATCH V2 4/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get

2018-09-07 Thread Michal Hocko
On Fri 07-09-18 16:45:09, Aneesh Kumar K.V wrote: > On 09/07/2018 02:33 PM, Michal Hocko wrote: > > On Thu 06-09-18 19:00:43, Aneesh Kumar K.V wrote: > > > On 09/06/2018 06:23 PM, Michal Hocko wrote: > > > > On Thu 06-09-18 11:13:42, Aneesh Kumar K.V wrote: > >

Re: [RFC PATCH V2 4/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get

2018-09-07 Thread Michal Hocko
On Thu 06-09-18 19:00:43, Aneesh Kumar K.V wrote: > On 09/06/2018 06:23 PM, Michal Hocko wrote: > > On Thu 06-09-18 11:13:42, Aneesh Kumar K.V wrote: > > > Current code doesn't do page migration if the page allocated is a > > > compound page. > > > With Huge

Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address

2018-09-07 Thread Michal Hocko
On Fri 07-09-18 11:42:12, Mike Rapoport wrote: > On Thu, Sep 06, 2018 at 03:46:27PM +0200, Michal Hocko wrote: > > On Thu 06-09-18 16:39:58, Mike Rapoport wrote: > > > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote: > > > > On Thu 06-09-18

Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address

2018-09-06 Thread Michal Hocko
On Thu 06-09-18 16:39:58, Mike Rapoport wrote: > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote: > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > > > On Wed 05-09-18

Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address

2018-09-06 Thread Michal Hocko
On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > > On Wed, Sep 5, 2018 at 11:00 AM

Re: [RFC PATCH V2 4/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get

2018-09-06 Thread Michal Hocko
pages. Pinned pages are not reclaimable as well so there is a risk of OOMs if there are too many of them. We have discussed approaches that would allow to force pin invalidation/revocation at LSF/MM. Isn't that a more appropriate solution to the problem you are seeing? -- Michal Hocko SUSE Labs

Re: [RFC PATCH V2 2/4] mm: Add get_user_pages_cma_migrate

2018-09-06 Thread Michal Hocko
describe why you are bypassing hugetlb pools. I assume that the reason is to guarantee a forward progress because those might be sitting in the CMA pools already, right? -- Michal Hocko SUSE Labs

Re: [RFC PATCH V2 1/4] mm: Export alloc_migrate_huge_page

2018-09-06 Thread Michal Hocko
On Thu 06-09-18 14:31:11, Michal Hocko wrote: > On Thu 06-09-18 11:13:39, Aneesh Kumar K.V wrote: > > We want to use this to support customized huge page migration. > > Please be much more specific. Ideally including the user. Btw. why do > you want to skip the hugetlb poo

Re: [RFC PATCH V2 1/4] mm: Export alloc_migrate_huge_page

2018-09-06 Thread Michal Hocko
use? -- Michal Hocko SUSE Labs

Re: [RFC PATCH 00/29] mm: remove bootmem allocator

2018-09-06 Thread Michal Hocko
this. I wish we could simplify the memblock API as well. There are just too many public functions with subtly different semantic and barely any useful documentation. But even this is a great step forward! -- Michal Hocko SUSE Labs

Re: [RFC PATCH 28/29] memblock: replace BOOTMEM_ALLOC_* with MEMBLOCK variants

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:43, Mike Rapoport wrote: > Drop BOOTMEM_ALLOC_ACCESSIBLE and BOOTMEM_ALLOC_ANYWHERE in favor of > identical MEMBLOCK definitions. > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > arch/ia64/mm/discontig.c | 2 +- > arch/powerpc/

Re: [RFC PATCH 27/29] mm: remove nobootmem

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:42, Mike Rapoport wrote: > Move a few remaining functions from nobootmem.c to memblock.c and remove > nobootmem > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > mm/Makefile| 1 - >

Re: [RFC PATCH 26/29] memblock: rename __free_pages_bootmem to memblock_free_pages

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:41, Mike Rapoport wrote: > The conversion is done using > > sed -i 's@__free_pages_bootmem@memblock_free_pages@' \ > $(git grep -l __free_pages_bootmem) > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > mm/internal.h | 2 +

Re: [RFC PATCH 25/29] memblock: rename free_all_bootmem to memblock_free_all

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:40, Mike Rapoport wrote: > The conversion is done using > > sed -i 's@free_all_bootmem@memblock_free_all@' \ > $(git grep -l free_all_bootmem) > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs

Re: [RFC PATCH 24/29] memblock: replace free_bootmem_late with memblock_free_late

2018-09-06 Thread Michal Hocko
bootmem variant. > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > arch/sparc/kernel/mdesc.c | 3 ++- > arch/x86/platform/efi/quirks.c | 6 +++--- > drivers/firmware/efi/apple-properties.c | 2 +- > include/linux/bootmem.h

Re: [RFC PATCH 23/29] memblock: replace free_bootmem{_node} with memblock_free

2018-09-06 Thread Michal Hocko
> - free_bootmem(e1, e2) > + memblock_free(e1, e2) > | > - free_bootmem_node(e1, e2, e3) > + memblock_free(e2, e3) > ) > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > arch/alpha/kernel/core_irongate.c | 3 +-- > arch/arm64/mm/init.c | 2 +- >

Re: [RFC PATCH 22/29] mm: nobootmem: remove bootmem allocation APIs

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:37, Mike Rapoport wrote: > The bootmem compatibility APIs are not used and can be removed. > > Signed-off-by: Mike Rapoport I am happy to see this finally go Acked-by: Michal Hocko > --- > include/linux/bootmem.h | 47 -- > mm/nobootme

Re: [RFC PATCH 21/29] memblock: replace alloc_bootmem with memblock_alloc

2018-09-06 Thread Michal Hocko
it a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c > index e8ae2e5..332fcca 100644 > --- a/drivers/macintosh/smu.c > +++ b/drivers/macintosh/smu.c > @@ -493,7 +493,7 @@ int __init smu_init (void) > goto fail_np; > } > > - smu = alloc_bootmem(sizeof(struct smu_device)); > + smu = memblock_alloc(sizeof(struct smu_device), 0); > > spin_lock_init(>lock); > INIT_LIST_HEAD(>cmd_list); > diff --git a/init/main.c b/init/main.c > index d0b92bd..99a9e99 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -768,8 +768,8 @@ static int __init initcall_blacklist(char *str) > str_entry = strsep(, ","); > if (str_entry) { > pr_debug("blacklisting initcall %s\n", str_entry); > - entry = alloc_bootmem(sizeof(*entry)); > - entry->buf = alloc_bootmem(strlen(str_entry) + 1); > + entry = memblock_alloc(sizeof(*entry), 0); > + entry->buf = memblock_alloc(strlen(str_entry) + 1, 0); > strcpy(entry->buf, str_entry); > list_add(>next, _initcalls); > } > -- > 2.7.4 > -- Michal Hocko SUSE Labs

Re: [RFC PATCH 20/29] memblock: replace __alloc_bootmem with memblock_alloc_from

2018-09-06 Thread Michal Hocko
block_alloc_from(size, SMP_CACHE_BYTES, 0UL); > > for (ctx = 0; ctx < numctx; ctx++) { > struct ctx_list *clist; > diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h > index 3896af2..c97c105 100644 > --- a/include/linux/bootmem.h > +++ b/include/linux/bootmem.h > @@ -122,6 +122,14 @@ static inline void * __init memblock_alloc_raw( > NUMA_NO_NODE); > } > > +static inline void * __init memblock_alloc_from( > + phys_addr_t size, phys_addr_t align, phys_addr_t min_addr) > +{ > + return memblock_alloc_try_nid(size, align, min_addr, > + BOOTMEM_ALLOC_ACCESSIBLE, > + NUMA_NO_NODE); > +} > + > static inline void * __init memblock_alloc_nopanic( > phys_addr_t size, phys_addr_t align) > { > -- > 2.7.4 > -- Michal Hocko SUSE Labs

Re: [RFC PATCH 19/29] memblock: replace alloc_bootmem_pages with memblock_alloc

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:34, Mike Rapoport wrote: > The conversion is done using the following semantic patch: > > @@ > expression e; > @@ > - alloc_bootmem_pages(e) > + memblock_alloc(e, PAGE_SIZE) > > Signed-off-by: Mike Rapoport Same as the previous pa

Re: [RFC PATCH 18/29] memblock: replace alloc_bootmem_low_pages with memblock_alloc_low

2018-09-06 Thread Michal Hocko
do the right thing and from a quick glance it looks sane (modulo _virt naming) Acked-by: Michal Hocko > --- > arch/arc/mm/highmem.c| 2 +- > arch/m68k/atari/stram.c | 3 ++- > arch/m68k/mm/motorola.c | 5 +++-- > arch/mips/cavium-o

Re: [RFC PATCH 17/29] memblock: replace alloc_bootmem_node with memblock_alloc_node

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:32, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport ENOCHAGELOG again The conversion itself looks good to me Acked-by: Michal Hocko > --- > arch/alpha/kernel/pci_iommu.c | 4 ++-- > arch/ia64/sn/kernel/io_common.c | 7 ++- > arch/ia64/sn/kernel/

Re: [RFC PATCH 16/29] memblock: replace __alloc_bootmem_node with appropriate memblock_ API

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:31, Mike Rapoport wrote: > Use memblock_alloc_try_nid whenever goal (i.e. mininal address is > specified) and memblock_alloc_node otherwise. I suspect you wanted to say (i.e. minimal address) is specified > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko

Re: [RFC PATCH 04/29] mm: remove bootmem allocator implementation.

2018-09-06 Thread Michal Hocko
On Thu 06-09-18 09:30:23, Michal Hocko wrote: > Is there any reason to keep > > ifdef CONFIG_NO_BOOTMEM > obj-y += nobootmem.o > else > obj-y += bootmem.o > endif > > behind? I can see you have done so in an earlier patch. I have mi

Re: [RFC PATCH 15/29] memblock: replace alloc_bootmem_pages_node with memblock_alloc_node

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:30, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport again a short work of wisdom please. The change itself looks good. Acked-by: Michal Hocko > --- > arch/ia64/mm/init.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --

Re: [RFC PATCH 14/29] memblock: add align parameter to memblock_alloc_node()

2018-09-06 Thread Michal Hocko
vailable()) > section = kzalloc_node(array_size, GFP_KERNEL, nid); > else > - section = memblock_alloc_node(array_size, nid); > + section = memblock_alloc_node(array_size, 0, nid); > > return section; > } > -- > 2.7.4 > -- Michal Hocko SUSE Labs

Re: [RFC PATCH 13/29] memblock: replace __alloc_bootmem_nopanic with memblock_alloc_from_nopanic

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:28, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport The translation is simpler here but still a word or two would be nice. Empty changelogs suck. To the change Acked-by: Michal Hocko > --- > arch/arc/kernel/unwind.c | 4 ++-- > arch/x86/kernel/se

Re: [RFC PATCH 12/29] memblock: replace alloc_bootmem_low with memblock_alloc_low

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:27, Mike Rapoport wrote: > The alloc_bootmem_low(size) allocates low memory with default alignement > and can be replcaed by memblock_alloc_low(size, 0) > > Signed-off-by: Mike Rapoport Again _virt renaming thing... Acked-by: Michal Hocko > --- >

Re: [RFC PATCH 11/29] memblock: replace alloc_bootmem_pages_nopanic with memblock_alloc_nopanic

2018-09-06 Thread Michal Hocko
deep down the callpath to see they are doing the same thing essentially. > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > drivers/usb/early/xhci-dbc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/early/xhci-dbc.c b/d

Re: [RFC PATCH 10/29] memblock: replace __alloc_bootmem_node_nopanic with memblock_alloc_try_nid_nopanic

2018-09-06 Thread Michal Hocko
t node if the given one doesn't have a proper range. So good. Lack of proper documentation didn't really help. > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > arch/x86/kernel/setup_percpu.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff

Re: [RFC PATCH 09/29] memblock: replace alloc_bootmem_low with memblock_alloc_low

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:24, Mike Rapoport wrote: > The functions are equivalent, just the later does not require nobootmem > translation layer. > > Signed-off-by: Mike Rapoport modulo @memblock_alloc_low@@memblock_virt_alloc_low@ Acked-by: Michal Hocko > --- > arch/x86/k

Re: [RFC PATCH 08/29] memblock: replace alloc_bootmem_align with memblock_alloc

2018-09-06 Thread Michal Hocko
On Wed 05-09-18 18:59:23, Mike Rapoport wrote: > The functions are equivalent, just the later does not require nobootmem > translation layer. > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > arch/x86/xen/p2m.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [RFC PATCH 06/29] memblock: rename memblock_alloc{_nid, _try_nid} to memblock_phys_alloc*

2018-09-06 Thread Michal Hocko
le checked the resulting patch but the change makes sense to me Acked-by: Michal Hocko > --- > arch/arm/mm/mmu.c | 2 +- > arch/arm64/mm/mmu.c | 2 +- > arch/arm64/mm/numa.c | 2 +- > arch/c6x/mm/dma-coherent.c

Re: [RFC PATCH 04/29] mm: remove bootmem allocator implementation.

2018-09-06 Thread Michal Hocko
obj-y += bootmem.o endif behind? > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko > --- > include/linux/bootmem.h | 16 - > mm/bootmem.c| 811 > > 2 files changed, 827 deletions(-) > delete mode 100

Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address

2018-09-06 Thread Michal Hocko
virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > And for consistency I've changed the memblock_virt_alloc as well. I would keep the current API unless the name is terribly misleading or it can be improved a lot. Neither seems to be the case here. So I would rather stick with the status quo. -- Michal Hocko SUSE Labs

Re: Infinite looping observed in __offline_pages

2018-08-23 Thread Michal Hocko
on-migratable huge page sizes. Something like: > > if (PageHuge(page) && > hugepage_migration_supported(page_hstate(page))) { Ohh, definitely, this is much better. -- Michal Hocko SUSE Labs

Re: Infinite looping observed in __offline_pages

2018-08-22 Thread Michal Hocko
On Wed 22-08-18 15:00:18, Aneesh Kumar K.V wrote: > > Hi Michal, > > Michal Hocko writes: > > > On Wed 25-07-18 13:11:15, John Allen wrote: > > [...] > >> Does a failure in do_migrate_range indicate that the range is unmigratable > >> and the loop

Re: Odd SIGSEGV issue introduced by commit 6b31d5955cb29 ("mm, oom: fix potential data corruption when oom_reaper races with writer")

2018-08-20 Thread Michal Hocko
see any oom killer invocations preceeding the SEGV? Some of those killed tasks simply do not look like a sensible oom victims (e.g. touch)... > And I bisected its disappearance with commit 99cd1302327a2 ("powerpc: > Deliver SEGV signal on pkey violation") Those two seem completely unrelated. -- Michal Hocko SUSE Labs

Re: [PATCH v6 00/11] hugetlb: Factorize hugetlb architecture primitives

2018-08-20 Thread Michal Hocko
clusion ? > > Thanks for your time, I didn't really get to look at the series but seeing an Ack from Mike and arch maintainers should be good enough for it to go. This email doesn't have Andrew Morton in the CC list so you should add him if you want the series to land into the mm tree. -- Michal Hocko SUSE Labs

Re: Infinite looping observed in __offline_pages

2018-08-01 Thread Michal Hocko
On Wed 01-08-18 21:09:39, Michael Ellerman wrote: > Michal Hocko writes: > > On Wed 25-07-18 13:11:15, John Allen wrote: > > [...] > >> Does a failure in do_migrate_range indicate that the range is unmigratable > >> and the loop in __offline_pages should

Re: Infinite looping observed in __offline_pages

2018-07-30 Thread Michal Hocko
On Fri 27-07-18 12:32:59, John Allen wrote: > On Wed, Jul 25, 2018 at 10:03:36PM +0200, Michal Hocko wrote: > > On Wed 25-07-18 13:11:15, John Allen wrote: > > [...] > > > Does a failure in do_migrate_range indicate that the range is unmigratable > > > and t

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-26 Thread Michal Hocko
On Thu 26-07-18 21:37:05, Baoquan He wrote: > On 07/26/18 at 03:14pm, Michal Hocko wrote: > > On Thu 26-07-18 15:12:42, Michal Hocko wrote: > > > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > > > On 07/26/18 at 02:59pm, Michal Hocko wrote: > > > > &g

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-26 Thread Michal Hocko
On Thu 26-07-18 15:12:42, Michal Hocko wrote: > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > On 07/26/18 at 02:59pm, Michal Hocko wrote: > > > On Wed 25-07-18 14:48:13, Baoquan He wrote: > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote: > > > > &g

  1   2   3   >