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
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
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
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
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
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:
> > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > >
On Wed 25-07-18 14:48:13, Baoquan He wrote:
> On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > Kexec has been a formal feature in our distro, and customers owning
> > > those kind of very large machine can make use of thi
give us more information. The
current debugging code in the hotplug/migration sucks...
--
Michal Hocko
SUSE Labs
ot have the full context here but let me note that you should be
careful when doing top-down reservation because you can easily get into
hotplugable memory and break the hotremove usecase. We even warn when
this is done. See memblock_find_in_range_node
--
Michal Hocko
SUSE Labs
On Wed 18-07-18 21:52:17, Mahesh Jagannath Salgaonkar wrote:
> On 07/17/2018 05:22 PM, Michal Hocko wrote:
> > On Tue 17-07-18 16:58:10, Mahesh Jagannath Salgaonkar wrote:
> >> On 07/16/2018 01:56 PM, Michal Hocko wrote:
> >>> On Mon 16-07-18 11:32:56, Mahesh
On Tue 17-07-18 16:58:10, Mahesh Jagannath Salgaonkar wrote:
> On 07/16/2018 01:56 PM, Michal Hocko wrote:
> > On Mon 16-07-18 11:32:56, Mahesh J Salgaonkar wrote:
> >> One of the primary issues with Firmware Assisted Dump (fadump) on Power
> >> is that it nee
otplug-memory.c |7 +
> include/linux/mmzone.h |2
> mm/page_alloc.c | 146
> ++
> 6 files changed, 290 insertions(+), 13 deletions(-)
This is quite a large change and you didn't seem to explain why we need
it.
--
Michal Hocko
SUSE Labs
On Wed 11-07-18 16:35:28, Joonsoo Kim wrote:
> 2018-07-10 18:50 GMT+09:00 Michal Hocko :
> > On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
> >> Hello, Marek.
> >>
> >> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski :
> >> > cma_alloc() func
lthough gfp_mask isn't used in cma_alloc() except no_warn, it can be used
> in alloc_contig_range(). For example, if passed gfp mask has no __GFP_FS,
> compaction(isolation) would work differently. Do you have considered
> such a case?
Does any of cma_alloc users actually care about GFP_NO{FS,IO}?
--
Michal Hocko
SUSE Labs
powerpc/include/asm/nohash/64/pgtable.h | 1 +
> arch/sh/include/asm/hugetlb.h| 54 ++---
> arch/sparc/include/asm/hugetlb.h | 40 +++--
> arch/x86/include/asm/hugetlb.h | 72 +--
> include/asm-generic/hugetlb.h| 88
> +++-
> 15 files changed, 143 insertions(+), 384 deletions(-)
>
> --
> 2.16.2
--
Michal Hocko
SUSE Labs
sense to me. If there is a real need for the
gfp_mask then we should start by defining the semantic first.
Acked-by: Michal Hocko
> ---
> arch/powerpc/kvm/book3s_hv_builtin.c | 2 +-
> drivers/s390/char/vmcp.c | 2 +-
> drivers/staging/android/ion/ion_cma_heap.c | 2 +-
On Thu 26-04-18 22:29:17, LEROY Christophe wrote:
> Michal Hocko <mho...@kernel.org> a écrit :
[...]
> > Yes, show_migration_types. But I do not see why unmovable pageblocks
> > should block the allocation. This is a GFP_KERNEL allocation request
> > essentia
On Thu 26-04-18 15:28:46, Christophe LEROY wrote:
>
>
> Le 26/04/2018 à 15:11, Michal Hocko a écrit :
> > On Thu 26-04-18 08:10:30, Christophe LEROY wrote:
> > >
> > >
> > > Le 25/04/2018 à 21:57, David Rientjes a écrit :
> >
is order-1, likely the
> > allocation of a struct task_struct for a new process on fork.
>
> I'm not sure I understand what you mean. The allocation is order 1, yes,
> does it explains why OOM killer is invoked ?
Well, not really
[ 54.437414] DMA: 460*4kB (UH) 201*8kB (UH) 121*16kB (UH) 43*32kB (UH)
10*64kB (U) 4*128kB (UH) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB =
7912kB`
You should have enough order-1+ pages to proceed.
--
Michal Hocko
SUSE Labs
On Wed 11-04-18 12:32:07, Laurent Dufour wrote:
[...]
> Andrew, should I send a v4 or could you wipe the 2 __maybe_unsued when
> applying
> the patch ?
A follow $patch-fix should be better rather than post this again and
spam people with more emails.
--
Michal Hocko
SUSE Labs
On Wed 11-04-18 10:41:23, Laurent Dufour wrote:
> On 11/04/2018 10:33, Michal Hocko wrote:
> > On Wed 11-04-18 10:03:36, Laurent Dufour wrote:
> >> @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct
> >> *vma, unsigned long addr,
> &g
ted-by: Jerome Glisse <jglisse@redhat>
> Reviewed-by: Jerome Glisse <jglisse@redhat>
> Acked-by: David Rientjes <rient...@google.com>
> Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com>
Looks good to me. I have checked x86 and the generic code and it looks
good to me. Anyway arch maintainers really have to double check this.
--
Michal Hocko
SUSE Labs
page tables.
>* eg. VDSO mappings can cause them to exist.
>*/
> -out:
> +out: __maybe_unused
> return pfn_to_page(pfn);
Why do we need this ugliness all of the sudden?
--
Michal Hocko
SUSE Labs
| 4 ++--
> mm/memory.c | 2 +-
> 23 files changed, 18 insertions(+), 24 deletions(-)
>
> --
> 2.7.4
--
Michal Hocko
SUSE Labs
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018, at 10:24, Michal Hocko <mho...@kernel.org> wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mho...@kernel.org> wr
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko <mho...@kernel.org> wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox <wi...@infradead.org
d this address if it is occupied for example and allocate just before
> closest vma. So this solution doesn’t give that much security like
> randomization address inside kernel.
The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
address range atomically and chose a different range on failure.
--
Michal Hocko
SUSE Labs
rather than doing small changes here and
there and reach v20 quickly.
I am planning to find some time to look at it but the spare cycles are
so rare these days...
--
Michal Hocko
SUSE Labs
On Thu 22-02-18 09:30:35, Kees Cook wrote:
> On Thu, Feb 22, 2018 at 5:07 AM, Michal Hocko <mho...@kernel.org> wrote:
> > On Wed 14-02-18 09:14:47, Kees Cook wrote:
> > [...]
> >> I can send it through my seccomp tree via James Morris.
> >
> > Could you pl
On Wed 14-02-18 09:14:47, Kees Cook wrote:
[...]
> I can send it through my seccomp tree via James Morris.
Could you please do it?
> >
> > From 8d8457e96296538508e478f598d1c8b3406a8626 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mho...@suse.com>
> > Date
On Tue 13-02-18 13:27:30, Kees Cook wrote:
> On Tue, Feb 13, 2018 at 2:32 AM, Michal Hocko <mho...@kernel.org> wrote:
> > On Tue 13-02-18 21:16:55, Michael Ellerman wrote:
> >> Kees Cook <keesc...@chromium.org> writes:
> >>
> >> > O
On Tue 13-02-18 21:16:55, Michael Ellerman wrote:
> Kees Cook <keesc...@chromium.org> writes:
>
> > On Mon, Feb 12, 2018 at 7:25 PM, Michael Ellerman <m...@ellerman.id.au>
> > wrote:
> >> Michal Hocko <mho...@kernel.org> writes:
> >>> Hi
On Mon 12-02-18 21:54:39, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 7:25 PM, Michael Ellerman <m...@ellerman.id.au> wrote:
> > Michal Hocko <mho...@kernel.org> writes:
> >> Hi,
> >> my build test machinery chokes on samples/seccomp when cross compiling
>
("samples/seccomp/Makefile: do not build tests if
cross-compiling for MIPS").
The build logs are attached.
What is the best way around this? Should we simply skip compilation on
cross compile or is actually anybody relying on that? Or should I simply
disable it for s390 and ppc?
--
Michal
anks for reworking this patch. Looks good to me.
> Signed-off-by: Ram Pai <linux...@us.ibm.com>
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> arch/x86/include/asm/pkeys.h |1 +
> arch/x86/kernel/fpu/xstate.c |5 +
> arch/x86/kernel/setu
re? The previous patch should make
arch_pkeys_enabled == F when CONFIG_ARCH_HAS_PKEYS=n. Btw. could you
merge those two patches into one. It is usually much easier to review a
new helper function if it is added along with a user.
> m_cache_vma(m, vma);
> return ret;
> }
> --
> 1.7.1
--
Michal Hocko
SUSE Labs
On Mon 08-01-18 13:27:13, Dan Williams wrote:
> On Mon, Jan 8, 2018 at 12:25 PM, Michal Hocko <mho...@kernel.org> wrote:
> > On Mon 08-01-18 11:44:02, Dan Williams wrote:
> >> On Mon, Jan 8, 2018 at 3:26 AM, Christoph Hellwig <h...@lst.de> wrote:
> >>
n go ahead and merge
it. Times are just too crazy right now.
Sorry about that.
--
Michal Hocko
SUSE Labs
Y_HOTPLUG disabled.
There is slight risk that we will encounter corner cases on some
architectures with weird memory layout/topology but we should better
explicitly disable this code rather than make it opt-in so this looks
like an improvement to me.
> Signed-off-by: Pavel Tatashin <pasha.ta
On Tue 14-11-17 20:18:04, Michael Ellerman wrote:
> Michal Hocko <mho...@kernel.org> writes:
>
> > [Sorry for spamming, this one is the last attempt hopefully]
> >
> > On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> >> On Mon 13-11-17 16:16:41, Michal Hocko
On Tue 14-11-17 19:54:59, Michael Ellerman wrote:
> Michal Hocko <mho...@kernel.org> writes:
[...]
> > So this was the most simple solution I could come up
> > with. If there was a general interest for MAP_FIXED_SAFE then we can
> > introduce it later of course. I wo
On Mon 13-11-17 09:35:22, Khalid Aziz wrote:
> On 11/13/2017 09:06 AM, Michal Hocko wrote:
> > OK, so this one should take care of the backward compatibility while
> > still not touching the arch code
> > ---
> > commit 39ff9bf8597e79a032da0954aea1f0d77d137765
&g
[Sorry for spamming, this one is the last attempt hopefully]
On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous emai
On Mon 13-11-17 15:48:13, Russell King - ARM Linux wrote:
> On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous email but the amount of code
> > >
On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
> > Yes, I have mentioned that in the previous email but the amount of code
> > would be even larger. Basically every arch which reimplements
> > arch_get_unmapped_area wo
On Mon 13-11-17 15:09:09, Russell King - ARM Linux wrote:
> On Mon, Nov 13, 2017 at 03:11:40PM +0100, Michal Hocko wrote:
> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> > > [Cc arm and ppc maintainers]
> > >
> > > Thanks a lot for testing!
> > >
On Mon 13-11-17 13:00:57, Michal Hocko wrote:
[...]
> Yes, I have mentioned that in the previous email but the amount of code
> would be even larger. Basically every arch which reimplements
> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> do vma lookup.
I
On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
>
> Thanks a lot for testing!
>
> On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <mho...@kernel.org> wrote:
> > > Hi Joel,
> >
On Mon 13-11-17 22:34:50, Michael Ellerman wrote:
> Hi Michal,
>
> Michal Hocko <mho...@kernel.org> writes:
> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> >> [Cc arm and ppc maintainers]
> >
> > Hmm, it turned out to be a problem on other archite
On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
Hmm, it turned out to be a problem on other architectures as well.
CCing more maintainers. For your reference, we are talking about
http://lkml.kernel.org/r/20171023082608.6167-1-mho...@kernel.org
which has bro
[Cc arm and ppc maintainers]
Thanks a lot for testing!
On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <mho...@kernel.org> wrote:
> > Hi Joel,
> >
> > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > [...]
&
Hi Abdul,
On Tue 07-11-17 11:28:54, Michal Hocko wrote:
> On Tue 07-11-17 15:20:29, Abdul Haleem wrote:
> > Hi,
> >
> > Today's next kernel fails to boot on Power 7 Machine with below errors
> > in boot log messages.
> >
> > 'Uhuuh, elf segement at 00
On Tue 07-11-17 11:28:54, Michal Hocko wrote:
> On Tue 07-11-17 15:20:29, Abdul Haleem wrote:
> > Hi,
> >
> > Today's next kernel fails to boot on Power 7 Machine with below errors
> > in boot log messages.
> >
> > 'Uhuuh, elf segement at 1004
vma->vm_mm->start_stack)
+ name = "[stack]";
+ }
+ pr_cont(" name:%s\n", name);
+ } else
+ pr_info("Uhm, no clashing VMA\n");
+ up_read(>mmap_sem);
return -EAGAIN;
}
--
Michal Hocko
SUSE Labs
ct the code can be further simplified but again this is nothing to
block this to go.
> Signed-off-by: Pavel Tatashin <pasha.tatas...@oracle.com>
> Reviewed-by: Steven Sistare <steven.sist...@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com
. The perfomance improvements are a bonus on
top.
Thanks, good work!
--
Michal Hocko
SUSE Labs
On Tue 10-10-17 15:44:41, Michal Hocko wrote:
> On Mon 09-10-17 18:19:27, Pavel Tatashin wrote:
> > Some memory is reserved but unavailable: not present in memblock.memory
> > (because not backed by physical pages), but present in memblock.reserved.
> > Such memory has
ed-off-by: Pavel Tatashin <pasha.tatas...@oracle.com>
> Reviewed-by: Steven Sistare <steven.sist...@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
Acked-by: Michal Hocko <mho...@suse.com>
&
fn 0.
Hmm, this is really interesting! I thought each memblock is guaranteed
to be section size aligned. But I suspect this is more of a wishful
thinking. But now I see what is the problem.
--
Michal Hocko
SUSE Labs
fix it up but right now I would rather
go a simpler path.
--
Michal Hocko
SUSE Labs
ages", pgcnt);
> +}
> +#endif /* CONFIG_HAVE_MEMBLOCK */
> +
> #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>
> #if MAX_NUMNODES > 1
> @@ -6632,6 +6668,7 @@ void __init free_area_init_nodes(unsigned long
> *max_zone_pfn)
> node_set_state(nid, N_MEMORY);
> check_for_memory(pgdat, nid);
> }
> + zero_resv_unavail();
> }
>
> static int __init cmdline_parse_core(char *p, unsigned long *core)
> @@ -6795,6 +6832,7 @@ void __init free_area_init(unsigned long *zones_size)
> {
> free_area_init_node(0, zones_size,
> __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> + zero_resv_unavail();
> }
>
> static int page_alloc_cpu_dead(unsigned int cpu)
> --
> 2.14.2
--
Michal Hocko
SUSE Labs
On Fri 06-10-17 12:11:42, David Laight wrote:
> From: Michal Hocko
> > Sent: 06 October 2017 12:47
> > On Fri 06-10-17 11:10:14, David Laight wrote:
> > > From: Pavel Tatashin
> > > > Sent: 05 October 2017 22:11
> > > > vmemmap_alloc_block
ry_nid_raw is a new
function which doesn't zero out...
--
Michal Hocko
SUSE Labs
ly sure that trim_low_memory_range is doing a sane and
really needed thing? In other words do we have a zone which contains
this no-memory backed pfns?
--
Michal Hocko
SUSE Labs
_memory_range code path. I am
not even sure we have to care about it because nobody should be walking
pfns outside of any zone. I am worried that this patch adds a code which
is not really used and it will just stay that way for ever because
nobody will dare to change it as it is too obscure and not
On Tue 03-10-17 11:29:16, Pasha Tatashin wrote:
> On 10/03/2017 09:18 AM, Michal Hocko wrote:
> > On Wed 20-09-17 16:17:10, Pavel Tatashin wrote:
> > > Some memory is reserved but unavailable: not present in memblock.memory
> > > (because not backed by p
adding any new branches, and the code is still going to stay
> compact.
OK. It is a bit clunky but we are holding too much state there. I
haven't checked whether that can be simplified but this can be always
done later.
--
Michal Hocko
SUSE Labs
On Tue 03-10-17 11:22:35, Pasha Tatashin wrote:
>
>
> On 10/03/2017 09:08 AM, Michal Hocko wrote:
> > On Wed 20-09-17 16:17:08, Pavel Tatashin wrote:
> > > Add struct page zeroing as a part of initialization of other fields in
> > > __init_single_page()
er in "stop zeroing ..."
I think that moving the zeroying in one go is more reasonable than
adding it to __init_single_page with misleading numbers and later
dropping the zeroying from the memmap path.
--
Michal Hocko
SUSE Labs
size = PAGE_ALIGN(size);
> - map = memblock_virt_alloc_try_nid(size * map_count,
> - PAGE_SIZE, __pa(MAX_DMA_ADDRESS),
> - BOOTMEM_ALLOC_ACCESSIBLE, nodeid);
> + map = memblock_virt_alloc_try_nid_raw(size * map_count,
> + PAGE_SIZE, __pa(MAX_DMA_ADDRESS),
> + BOOTMEM_ALLOC_ACCESSIBLE, nodeid);
> if (map) {
> for (pnum = pnum_begin; pnum < pnum_end; pnum++) {
> if (!present_section_nr(pnum))
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
> through __init_single_page().
Could you be more specific where is such a memory reserved?
--
Michal Hocko
SUSE Labs
> Signed-off-by: Pavel Tatashin <pasha.tatas...@oracle.com>
> Reviewed-by: Steven Sistare <steven.sist...@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
> Acked-by: Michal Hocko <mho.
gt; Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
> Acked-by: David S. Miller <da...@davemloft.net>
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> arch/sparc/mm/init_64.c | 23 ++-
&
nr_to_free);
> - free_base_page = NULL;
> - free_base_pfn = nr_to_free = 0;
> - }
> - /* Free the last block of pages to allocator */
> - nr_pages += nr_to_free;
> - deferred_free_range(free_base_page, free_base_pfn, nr_to_free);
> -
> - first_init_pfn = max(end_pfn, first_init_pfn);
> + for_each_free_mem_range(i, nid, MEMBLOCK_NONE, , , NULL) {
> + spfn = max_t(unsigned long, first_init_pfn, PFN_UP(spa));
> + epfn = min_t(unsigned long, zone_end_pfn(zone), PFN_DOWN(epa));
> + nr_pages += deferred_init_range(nid, zid, spfn, epfn);
> }
>
> /* Sanity check that the next zone really is unpopulated */
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
the above calls.
>
> Signed-off-by: Pavel Tatashin <pasha.tatas...@oracle.com>
> Reviewed-by: Steven Sistare <steven.sist...@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
> Acked-by:
ven Sistare <steven.sist...@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
I hope I haven't missed anything but it looks good to me.
Acked-by: Michal Hocko <mho...@suse.com>
one nit below
> ---
e
proc_dostring but I thought I was more clever. Sigh...
This should do the trick. Andrew, could you fold it into
mm-page_alloc-rip-out-zonelist_order_zone.patch please?
Thanks for the report Abdul!
---
commit 69885605ee3ba681deb54021e3df645f46589ba1
Author: Michal Hocko <mho...@suse.com>
rved)
>
> This is exactly what we need here. So, I will update this patch to use this
> iterator, which will simplify it.
Please have a look at
http://lkml.kernel.org/r/20170815093306.gc29...@dhcp22.suse.cz
I believe we can simply drop the check altogether.
--
Michal Hocko
SUSE Labs
edious than simply
adding one option to the kernel command line.
--
Michal Hocko
SUSE Labs
}
-
__init_single_page(page, pfn, zid, nid);
if (!free_base_page) {
free_base_page = page;
--
Michal Hocko
SUSE Labs
m("reservelow", parse_reservelow);
>
> static void __init trim_low_memory_range(void)
> {
> - memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
> + unsigned long min_pfn = find_min_pfn_with_active_regions();
> + phys_addr_t base = min_pfn << PAGE_SHIFT;
> +
> + memblock_reserve(base, ALIGN(reserve_low, PAGE_SIZE));
> }
>
> /*
> --
> 2.14.0
--
Michal Hocko
SUSE Labs
st for other reasons then just
update that as well. But nothing really earth shattering.
--
Michal Hocko
SUSE Labs
change it to CONFIG_MEMBLOCK_DEBUG,
> and let users decide what other debugging configs need to be enabled, as
> this is also OK.
Actually the more I think about it the more I am convinced that a kernel
boot parameter would be better because it doesn't need the kernel to be
recompiled and it is a single branch in not so hot path.
--
Michal Hocko
SUSE Labs
On Fri 11-08-17 11:55:39, Pasha Tatashin wrote:
> On 08/11/2017 05:37 AM, Michal Hocko wrote:
> >On Mon 07-08-17 16:38:39, Pavel Tatashin wrote:
> >>In deferred_init_memmap() where all deferred struct pages are initialized
> >>we have a check like this:
&g
art. Please make it explicit in the changelog.
It is quite easy to get lost in the deep call chains.
--
Michal Hocko
SUSE Labs
en we were setting reserved
> flags to struct page for PFN 0 in which was never initialized through
> __init_single_page(). The reason they were triggered is because we set all
> uninitialized memory to ones in one of the debug patches.
And why don't we need the same treatment for other architectures?
--
Michal Hocko
SUSE Labs
> Yes, they said that the problem was bisected down to this patch. Do you know
> if there is a way to submit a patch to this test robot?
You can ask them for re testing with an updated patch by replying to
their report. ANyway I fail to see how the change could lead to this
patch.
--
Michal Hocko
SUSE Labs
in
> nobootmem headfile.
This is the standard way to do this. And it is usually preferred to
proliferate ifdefs in the code.
--
Michal Hocko
SUSE Labs
On Fri 11-08-17 11:58:46, Pasha Tatashin wrote:
> On 08/11/2017 08:39 AM, Michal Hocko wrote:
> >On Mon 07-08-17 16:38:41, Pavel Tatashin wrote:
> >>A new variant of memblock_virt_alloc_* allocations:
> >>memblock_virt_alloc_try_nid_raw()
> >>
ring that some HW might behave strangely and this would be rather
> >hard to debug I would be tempted to mark this for stable. It should also
> >be merged separately from the rest of the series.
> >
> >I have just one nit below
> >Acked-by: Michal Hocko <mho...@suse.com>
>
On Fri 11-08-17 11:13:07, Pasha Tatashin wrote:
> On 08/11/2017 03:58 AM, Michal Hocko wrote:
> >[I am sorry I didn't get to your previous versions]
>
> Thank you for reviewing this work. I will address your comments, and
> send-out a new patches.
>
> >>
> &
eturn memblock_virt_alloc_internal(size, align,
> - min_addr, max_addr, nid);
> + ptr = memblock_virt_alloc_internal(size, align,
> +min_addr, max_addr, nid);
> +#ifdef CONFIG_DEBUG_VM
> + if (ptr &&a
by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
OK, but as mentioned in the previous patch add memblock_virt_alloc_raw
in this patch.
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> mm/page_alloc.c | 15 +++
IZE, __pa(MAX_DMA_ADDRESS),
> + BOOTMEM_ALLOC_ACCESSIBLE, nodeid);
> if (map) {
> for (pnum = pnum_begin; pnum < pnum_end; pnum++) {
> if (!present_section_nr(pnum))
> --
> 2.14.0
--
Michal Hocko
SUSE Labs
cal page numbers. However, mem_map only begins to
> record
> * per-page information starting at pfn_base. This is to handle systems
> where
> * the first physical page in the machine is at some huge physical address,
> --
> 2.14.0
--
Michal Hocko
SUSE Labs
.@oracle.com>
> Reviewed-by: Steven Sistare <steven.sist...@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
After the relevant information is added feel free add
Acked-by: Michal Hocko <mho.
Sistare <steven.sist...@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jor...@oracle.com>
> Reviewed-by: Bob Picco <bob.pi...@oracle.com>
other than that
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> include/linux/bo
_end_pfn);
> if (!pfn_valid_within(pfn))
> goto free_range;
>
> @@ -1524,7 +1529,11 @@ static int __init deferred_init_memmap(void *data)
> cond_resched();
> }
>
> - if (page->flags) {
> + /*
> + * Check if this page has already been initialized due
> + * to being reserved during boot in memblock.
> + */
> + if (pfn >= resv_start_pfn) {
> VM_BUG_ON(page_zone(page) != zone);
> goto free_range;
> }
> --
> 2.14.0
--
Michal Hocko
SUSE Labs
d this would be rather
hard to debug I would be tempted to mark this for stable. It should also
be merged separately from the rest of the series.
I have just one nit below
Acked-by: Michal Hocko <mho...@suse.com>
[...]
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2cb25fe4452c..bf14ae
ed, and free_all_bootmem() initializes all the reserved
> + * deferred pages for us.
> + */
> + register_page_bootmem_info();
> +
> /* Register memory areas for /proc/kcore */
> kclist_add(_vsyscall, (void *)VSYSCALL_ADDR,
>PAGE_SIZE, KCORE_OTHER);
> --
> 2.14.0
--
Michal Hocko
SUSE Labs
301 - 400 of 482 matches
Mail list logo
