On Thu, May 23, 2019 at 11:58 AM Pingfan Liu wrote:
>
> On Wed, May 22, 2019 at 7:16 PM Michal Hocko wrote:
> >
> > On Wed 22-05-19 15:12:16, Pingfan Liu wrote:
> > > On Mon, May 13, 2019 at 11:31 PM Michal Hocko wrote:
> > > >
> > > > On Mon
On Wed, May 22, 2019 at 7:16 PM Michal Hocko wrote:
>
> On Wed 22-05-19 15:12:16, Pingfan Liu wrote:
> > On Mon, May 13, 2019 at 11:31 PM Michal Hocko wrote:
> > >
> > > On Mon 13-05-19 11:20:46, Qian Cai wrote:
> > > > On Mon, 2019-05-13 at 16:04 +020
On Mon, May 13, 2019 at 11:31 PM Michal Hocko wrote:
>
> On Mon 13-05-19 11:20:46, Qian Cai wrote:
> > On Mon, 2019-05-13 at 16:04 +0200, Michal Hocko wrote:
> > > On Mon 13-05-19 09:43:59, Qian Cai wrote:
> > > > On Mon, 2019-05-13 at 14:41 +0200, Michal Hocko wrote:
> > > > > On Sun 12-05-19
On Tue, May 7, 2019 at 4:28 PM Ingo Molnar wrote:
>
>
> * Pingfan Liu wrote:
>
> > arch/x86/boot/compressed/head_64.S clears BSS after relocated. If early
> > serial is set up before clearing BSS, the early_serial_base will be reset
> > to 0.
> >
> > In
.com/linux-kernel@vger.kernel.org/msg1992919.html
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: "Kirill A. Shutemov"
Cc: Cao jin
Cc: Wei Huang
Cc: Chao Fan
Cc: Nicolai Stange
Cc: Dou Liyang
Cc: linux-kernel@vger.kernel.org
Pingfan Liu
Some idt routines can be reused in early boot stage. Splitting them out.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: "Kirill A. Shutemov"
Cc: Cao jin
Cc: Wei Huang
Cc: Chao Fan
Cc: Nicolai Stange
Cc: D
p, instead of adding more debug_putstr() to
narraw down the problem.
At present, page fault exception handler is added. And the printed out
message looks like:
early boot page fault:
ENTRY(startup_64) is at: 00047f67d200
nip: 00047fdeedd3
fault address: fffeef6fde30
Signed-off-b
arch/x86/boot/compressed/head_64.S clears BSS after relocated. If early
serial is set up before clearing BSS, the early_serial_base will be reset
to 0.
Initializing early_serial_base as -1 to push it to .data section.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav
At the very early boot stage, early console is badly needed. Push its
initialization as early as possible, just after stack is ready.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Jordan Borgner
Cc: linux-kernel@vger.
he parse_crashkernel_xx routines
v4 -> v5:
drop unnecessary initialization of crash_base in [2/2]
Pingfan Liu (2):
kernel/crash_core: separate the parsing routines to
lib/parse_crashkernel.c
x86/boot/KASLR: skip the specified crashkernel region
arch/x86/boot/compressed/kaslr.c | 40 +
crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
fail to reserve the required memory region if KASLR puts kernel into the
region. To avoid this uncertainty, asking KASLR to skip the required
region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc
Make the "crashkernel=" parsing functionality available to the early
KASLR code. Will be used by a later patch to parse crashkernel regions
which KASLR should aviod.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
On Thu, Apr 18, 2019 at 8:32 PM Borislav Petkov wrote:
>
> On Thu, Apr 18, 2019 at 03:56:09PM +0800, Pingfan Liu wrote:
> > Then in my case, either no @offset or invalid argument will keep
> > "*crash_base = 0", and KASLR does not care about either of them.
>
On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
>
>
[...]
> > @@ -139,6 +141,8 @@ static int __init parse_crashkernel_simple(char
> > *cmdline,
> > pr_warn("crashkernel: unrecognized char: %c\n", *cur);
> > return -EINVAL;
> > }
> > + if (*crash_size
On Thu, Apr 18, 2019 at 12:06 AM Borislav Petkov wrote:
>
> On Wed, Apr 17, 2019 at 01:53:37PM +0800, Pingfan Liu wrote:
> > Take __parse_crashkernel()->parse_crashkernel_simple() for example. If
> > no offset given, then it still return 0, but crash_base is dangling.
So
On Wed, Apr 17, 2019 at 3:01 AM Borislav Petkov wrote:
>
> On Mon, Apr 08, 2019 at 01:58:35PM +0800, Pingfan Liu wrote:
> > crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> > fail to reserve the required memory region if KASLR puts kernel into the
&g
On Wed, Apr 17, 2019 at 3:01 AM Borislav Petkov wrote:
>
> On Mon, Apr 08, 2019 at 01:58:34PM +0800, Pingfan Liu wrote:
> > Beside kernel, at early boot stage, the KASLR code also needs to parse the
> > crashkernel=x@y or crashkernel=ramsize-range:size[,...][@offset] option,
&g
crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
fail to reserve the required memory region if KASLR puts kernel into the
region. To avoid this uncertainty, asking KASLR to skip the required
region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc
by other
files.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Baoquan He
Cc: Will Deacon
Cc: Nicolas Pitre
Cc: Chao Fan
Cc: "Kirill A. Shutemov"
Cc: Ard Biesheuvel
Cc: Vivek Goyal
CC: Hari Bathi
he parse_crashkernel_xx routines
Pingfan Liu (2):
kernel/crash_core: separate the parsing routines to
lib/parse_crashkernel.c
x86/boot/KASLR: skip the specified crashkernel region
arch/x86/boot/compressed/kaslr.c | 40 ++
kernel/crash_core.c | 273 --
On Wed, Apr 3, 2019 at 11:10 AM Baoquan He wrote:
>
> On 04/03/19 at 10:58am, Pingfan Liu wrote:
> > On Tue, Apr 2, 2019 at 4:08 PM Baoquan He wrote:
> > >
> > > > +/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset
> &
On Tue, Apr 2, 2019 at 2:46 PM Baoquan He wrote:
>
> On 04/02/19 at 12:10pm, Pingfan Liu wrote:
> > crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> > fail to reserve the required memory region if KASLR puts kernel into the
> > region. To avoid
On Tue, Apr 2, 2019 at 4:08 PM Baoquan He wrote:
>
> > +/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset
> > options */
> > +static void mem_avoid_specified_crashkernel_region(char *option)
> > +{
> > + unsigned long long crash_size, crash_base = 0;
> > + char
On Tue, Apr 2, 2019 at 1:20 PM Chao Fan wrote:
>
> On Tue, Apr 02, 2019 at 12:10:46PM +0800, Pingfan Liu wrote:
> >crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> or or?
> >fail to reserve the required memory region if KASLR puts kernel into th
crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
fail to reserve the required memory region if KASLR puts kernel into the
region. To avoid this uncertainty, asking KASLR to skip the required
region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc
On Fri, Mar 29, 2019 at 3:34 PM Baoquan He wrote:
>
> On 03/29/19 at 03:25pm, Pingfan Liu wrote:
> > On Fri, Mar 29, 2019 at 2:27 PM Baoquan He wrote:
> > >
> > > On 03/29/19 at 01:45pm, Pingfan Liu wrote:
> > > > On Fri, Mar 22, 2019 at 4:34 PM Baoquan
On Fri, Mar 29, 2019 at 2:27 PM Baoquan He wrote:
>
> On 03/29/19 at 01:45pm, Pingfan Liu wrote:
> > On Fri, Mar 22, 2019 at 4:34 PM Baoquan He wrote:
> > >
> > > On 03/22/19 at 03:52pm, Baoquan He wrote:
> > > > On 03/22/19 at 03:43pm, Pingfan Liu wrot
On Fri, Mar 22, 2019 at 4:34 PM Baoquan He wrote:
>
> On 03/22/19 at 03:52pm, Baoquan He wrote:
> > On 03/22/19 at 03:43pm, Pingfan Liu wrote:
> > > > > +/* parse crashkernel=x@y option */
> > > > > +static void mem_avoid_crashkernel_simple(char *o
On Fri, Mar 22, 2019 at 4:34 PM Baoquan He wrote:
>
> On 03/22/19 at 03:52pm, Baoquan He wrote:
> > On 03/22/19 at 03:43pm, Pingfan Liu wrote:
> > > > > +/* parse crashkernel=x@y option */
> > > > > +static void mem_avoid_crashkernel_simple(char *o
On Thu, Mar 21, 2019 at 2:38 PM Chao Fan wrote:
>
> On Wed, Mar 13, 2019 at 12:19:31PM +0800, Pingfan Liu wrote:
>
> I tested it in Qemu test with 12G memory, and set crashkernel=6G@6G.
> Without this PATCH, it successed to reserve memory just 4 times(total
> 10 times).
On Wed, Mar 20, 2019 at 8:25 AM Baoquan He wrote:
>
> Please change subject as:
>
> "x86/boot/KASLR: skip the specified crashkernel region"
>
OK.
> Don't see why reserved is needed here.
>
> On 03/13/19 at 12:19pm, Pingfan Liu wrote:
> > crashkernel=x@y
crashkernel=x@y option may fail to reserve the required memory region if
KASLR puts kernel into the region. To avoid this uncertainty, making KASLR
skip the required region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
On Wed, Feb 27, 2019 at 3:40 PM Borislav Petkov wrote:
>
> + Kees.
>
> @Kees, you might want to go upthread a bit for context.
>
Seems not reply from Kees.
> On Wed, Feb 27, 2019 at 09:30:34AM +0800, Baoquan He wrote:
> > Agree that 'crashkernel=x' should be encouraged to use as the first
> >
On Tue, Feb 26, 2019 at 8:09 PM Michal Hocko wrote:
>
> On Tue 26-02-19 13:47:37, Pingfan Liu wrote:
> > On Tue, Feb 26, 2019 at 12:04 AM Michal Hocko wrote:
> > >
> > > On Sun 24-02-19 20:34:03, Pingfan Liu wrote:
> > > > There are NUMA machi
On Fri, Mar 1, 2019 at 11:04 AM Pingfan Liu wrote:
>
> Hi Borislav,
>
> Do you think the following patch is good at present?
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 81f9d23..9213073 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/ke
Hi Borislav,
Do you think the following patch is good at present?
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 81f9d23..9213073 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -460,7 +460,7 @@ static void __init
On Tue, Feb 26, 2019 at 7:58 PM Mike Rapoport wrote:
>
> On Sun, Feb 24, 2019 at 08:34:05PM +0800, Pingfan Liu wrote:
> > There are numa machines with memory-less node. When allocating memory for
> > the memory-less node, memblock allocator falls back to 'Node 0' without
>
On Tue, Feb 26, 2019 at 12:04 AM Michal Hocko wrote:
>
> On Sun 24-02-19 20:34:03, Pingfan Liu wrote:
> > There are NUMA machines with memory-less node. At present page allocator
> > builds the
> > full fallback info by build_zonelists(). But memblock allocat
On Mon, Feb 25, 2019 at 11:34 PM Dave Hansen wrote:
>
> On 2/24/19 4:34 AM, Pingfan Liu wrote:
> > +/*
> > + * build_node_order() relies on cpumask_of_node(), hence arch should
> > + * set up cpumask before calling this func.
> > + */
>
> Whenever I see comme
On Mon, Feb 25, 2019 at 11:24 PM Dave Hansen wrote:
>
> On 2/24/19 4:34 AM, Pingfan Liu wrote:
> > +#ifdef CONFIG_NUMA
> > /*
> > * There are unfortunately some poorly designed mainboards around that
> > * only connect memory to a single CPU. This breaks t
On Mon, Feb 25, 2019 at 11:30 PM Dave Hansen wrote:
>
> On 2/24/19 4:34 AM, Pingfan Liu wrote:
> > At present the node to cpumask map is set up until the secondary
> > cpu boot up. But it is too late for the purpose of building node fall back
> > list at early
On Mon, Feb 25, 2019 at 4:23 PM Chao Fan wrote:
>
> On Mon, Feb 25, 2019 at 03:59:56PM +0800, Pingfan Liu wrote:
> >crashkernel=x@y option may fail to reserve the required memory region if
> >KASLR puts kernel into the region. To avoid this uncertainty, making KASLR
> >
On Mon, Feb 25, 2019 at 5:45 PM Borislav Petkov wrote:
>
> On Mon, Feb 25, 2019 at 03:59:56PM +0800, Pingfan Liu wrote:
> > crashkernel=x@y option may fail to reserve the required memory region if
> > KASLR puts kernel into the region. To avoid this uncertainty, making KASLR
>
crashkernel=x@y option may fail to reserve the required memory region if
KASLR puts kernel into the region. To avoid this uncertainty, making KASLR
skip the required region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
On Fri, Feb 22, 2019 at 9:00 PM Borislav Petkov wrote:
>
> On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> > The current default of 256MB was found by experiments on a bigger
> > number of machines, to create a reasonable default that is at least
> > likely to be sufficient of an
After the previous patches, on x86, it is safe to call
memblock_build_node_order() after init_cpu_to_node(), which has set up node
to cpumask map. So calling memblock_build_node_order() to feed memblock with
numa node fall back info.
Signed-off-by: Pingfan Liu
CC: Thomas Gleixner
CC: Ingo
For non-NUMA, it turns out that numa_init_array() has no operations. Make
separated definition for non-NUMA and NUMA, so later they can be combined
into their counterpart init_cpu_to_node().
Signed-off-by: Pingfan Liu
CC: Thomas Gleixner
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter
Both numa_init_array() and init_cpu_to_node() aim at setting up the cpu to
node map, so combining them. And the coming patch will set up node to
cpumask map in the combined function.
Signed-off-by: Pingfan Liu
CC: Thomas Gleixner
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin
it by calling numa_add_cpu(cpu) in init_cpu_to_node().
Signed-off-by: Pingfan Liu
CC: Thomas Gleixner
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin"
CC: Dave Hansen
CC: Vlastimil Babka
CC: Mike Rapoport
CC: Andrew Morton
CC: Mel Gorman
CC: Joonsoo Kim
CC: Andy Lutomirski
en
CC: Petr Tesarik
CC: Michal Hocko
CC: Stephen Rothwell
CC: Jonathan Corbet
CC: Nicholas Piggin
CC: Daniel Vacek
CC: linux-kernel@vger.kernel.org
Pingfan Liu (6):
mm/numa: extract the code of building node fall back list
mm/memblock: make full utilization of numa info
x86/numa: de
In coming patch, memblock allocator also utilizes node fall back list info.
Hence extracting the related code for reusing.
Signed-off-by: Pingfan Liu
CC: Thomas Gleixner
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin"
CC: Dave Hansen
CC: Vlastimil Babka
CC: Mike Ra
back
info for memblock allocator, like what we have done for page allocator.
Signed-off-by: Pingfan Liu
CC: Thomas Gleixner
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin"
CC: Dave Hansen
CC: Vlastimil Babka
CC: Mike Rapoport
CC: Andrew Morton
CC: Mel Gorman
CC: Joons
On Wed, Feb 20, 2019 at 5:41 PM Dave Young wrote:
>
> On 02/20/19 at 09:32am, Borislav Petkov wrote:
> > On Mon, Feb 18, 2019 at 09:48:20AM +0800, Dave Young wrote:
> > > It is ideal if kernel can do it automatically, but I'm not sure if
> > > kernel can predict the swiotlb reserved size
On Mon, Feb 18, 2019 at 9:48 AM Dave Young wrote:
>
> On 02/15/19 at 11:24am, Borislav Petkov wrote:
> > On Tue, Feb 12, 2019 at 04:48:16AM +0800, Dave Young wrote:
> > > Even we make it automatic in kernel, but we have to have some default
> > > value for swiotlb in case crashkernel can not find
On Tue, Feb 12, 2019 at 4:48 AM Dave Young wrote:
>
> On 02/06/19 at 08:08pm, Dave Young wrote:
> > On 02/05/19 at 09:15am, Borislav Petkov wrote:
> > > On Mon, Feb 04, 2019 at 03:30:16PM -0700, Jerry Hoemann wrote:
> > > > Is your objection only to the second fallback of allocating
> > > >
Commit-ID: 439fbdf6a2021ab1cca94b30837674b2b7527ae8
Gitweb: https://git.kernel.org/tip/439fbdf6a2021ab1cca94b30837674b2b7527ae8
Author: Pingfan Liu
AuthorDate: Fri, 4 Jan 2019 16:46:19 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 29 Jan 2019 22:09:12 +0100
x86/trap: Remove
On Fri, Jan 25, 2019 at 6:39 PM Borislav Petkov wrote:
>
>
> > Subject: Re: [PATCHv7] x86/kdump: bugfix, make the behavior of
> > crashkernel=X
>
> s/bugfix, //
>
OK.
> On Mon, Jan 21, 2019 at 01:16:08PM +0800, Pingfan Liu wrote:
> > People reported
On Fri, Jan 25, 2019 at 10:08 PM Borislav Petkov wrote:
>
> On Fri, Jan 25, 2019 at 09:45:18PM +0800, Dave Young wrote:
> > AFAIK, some people prefer to explictly reserve crash memory at high
> > region even if it is possible to reserve at low area. May because
> > <4G memory is limited on large
On Sat, Jan 19, 2019 at 9:25 AM Jerry Hoemann wrote:
>
> On Tue, Jan 15, 2019 at 04:07:03PM +0800, Pingfan Liu wrote:
> > People reported a bug on a high end server with many pcie devices, where
> > kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> >
Signed-off-by: Pingfan Liu
Cc: Dave Young
Cc: Baoquan He
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: ying...@kernel.org,
Cc: vgo...@redhat.com
Cc: Randy Dunlap
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
v6 -> v7: commit log improvement
arch/x86/kernel/setup.c |
/lists.infradead.org/pipermail/kexec/2017-October/019571.html
There was an old discussion below (previously posted by Chao Wang):
https://lkml.org/lkml/2013/10/15/601
Signed-off-by: Pingfan Liu
Cc: Dave Young
Cc: Baoquan He
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: ying...@kernel.org,
Cc: vgo...@
On Mon, Jan 14, 2019 at 12:24 PM Randy Dunlap wrote:
>
> Hi,
>
> Just fix a few of the commit log comments...
>
> On 1/13/19 7:15 PM, Pingfan Liu wrote:
> > People reported a bug on a high end server with many pcie devices, where
> > kernel bootup with crashkernel=38
On Tue, Jan 15, 2019 at 7:27 AM Dave Hansen wrote:
>
> On 1/10/19 9:12 PM, Pingfan Liu wrote:
> > Although kaslr-kernel can avoid to stain the movable node. [1]
>
> Can you explain what staining is, or perhaps try to use some more
> standard nomenclature? There ar
On Tue, Jan 15, 2019 at 7:12 AM Dave Hansen wrote:
>
> On 1/10/19 9:12 PM, Pingfan Liu wrote:
> > The current acpi_table_upgrade() relies on initrd_start, but this var is
>
> "var" meaning variable?
>
> Could you please go back and try to ensure you spell out
On Tue, Jan 15, 2019 at 7:07 AM Dave Hansen wrote:
>
> On 1/10/19 9:12 PM, Pingfan Liu wrote:
> > This patch identifies the point where memblock alloc start. It has no
> > functional.
>
> It has no functional ... what? Effects?
>
During re-organize the code, it takes m
On Tue, Jan 15, 2019 at 7:02 AM Dave Hansen wrote:
>
> On 1/10/19 9:12 PM, Pingfan Liu wrote:
> > Background
> > When kaslr kernel can be guaranteed to sit inside unmovable node
> > after [1].
>
> What does this "[1]" refer to?
>
https://lore.kernel.or
[...]
> >
> > I would appreciate a help with those architectures because I couldn't
> > really grasp how the memoryless nodes are really initialized there. E.g.
> > ppc only seem to call setup_node_data for online nodes but I couldn't
> > find any special treatment for nodes without any memory.
>
On Mon, Jan 14, 2019 at 4:50 PM Mike Rapoport wrote:
>
> On Mon, Jan 14, 2019 at 04:33:50PM +0800, Pingfan Liu wrote:
> > On Mon, Jan 14, 2019 at 3:51 PM Mike Rapoport wrote:
> > >
> > > Hi Pingfan,
> > >
> > > On Fri, Jan 11, 2019 at 01:12:53PM +0
On Mon, Jan 14, 2019 at 3:51 PM Mike Rapoport wrote:
>
> Hi Pingfan,
>
> On Fri, Jan 11, 2019 at 01:12:53PM +0800, Pingfan Liu wrote:
> > During boot time, there is requirement to tell whether a series of func
> > call will consume memory or not. For some reason, a tempo
/lists.infradead.org/pipermail/kexec/2017-October/019571.html
There was an old discussion below (previously posted by Chao Wang):
https://lkml.org/lkml/2013/10/15/601
Signed-off-by: Pingfan Liu
Cc: Dave Young
Cc: Baoquan He
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: ying...@kernel.org,
Cc: vgo...@red
On Fri, Jan 11, 2019 at 1:31 PM Chao Fan wrote:
>
> On Fri, Jan 11, 2019 at 01:12:52PM +0800, Pingfan Liu wrote:
> >The current acpi_table_upgrade() relies on initrd_start, but this var is
> >only valid after relocate_initrd(). There is requirement to extract the
> >acpi
On Fri, Jan 11, 2019 at 2:13 PM Chao Fan wrote:
>
> On Fri, Jan 11, 2019 at 01:12:51PM +0800, Pingfan Liu wrote:
> >This patch identifies the point where memblock alloc start. It has no
> >functional.
> [...]
> >+#ifdef CONFIG_MEMORY_HOTPLUG
> >+ /*
>
,
the memblock allocator can work. About how memblock allocator steps around
the movable node, referring to the cond check on memblock_is_hotpluggable()
in __next_mem_range().
Later in this series, the bottom-up allocation style can be removed on x86_64.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
-by: Pingfan Liu
Acked-by: "Rafael J. Wysocki"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Yinghai Lu
Cc: Tejun Heo
Cc: Chao Fa
from the case: start > end.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Yinghai Lu
Cc: Tejun Heo
Cc: Chao
bottom-up style is useless in x86_64 any longer, isolate it. Later, it may
be removed completely from x86.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Ra
using 1GB page, different page
attr and fragment will make things worse. So it is hard to decide how much
should the gap increase.
[1]: https://lore.kernel.org/patchwork/patch/1029376/
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin&qu
This patch identifies the point where memblock alloc start. It has no
functional.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
people to resolve it.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Yinghai Lu
Cc: Tejun Heo
Cc: Chao Fan
Cc: Bao
stimil Babka
Cc: Michal Hocko
Cc: x...@kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
Pingfan Liu (7):
x86/mm: concentrate the code to memblock allocator enabled
acpi: change the topo of acpi_table_upgrade()
mm/memblock: introduce allocation boundary for tracing purpose
On Tue, Jan 8, 2019 at 10:34 PM Michal Hocko wrote:
>
> On Thu 20-12-18 10:19:34, Michal Hocko wrote:
> > On Thu 20-12-18 15:19:39, Pingfan Liu wrote:
> > > Hi Michal,
> > >
> > > WIth this patch applied on the old one, I got the following messa
On Wed, Jan 9, 2019 at 10:25 PM Baoquan He wrote:
>
> On 01/08/19 at 05:48pm, Mike Rapoport wrote:
> > On Tue, Jan 08, 2019 at 05:01:38PM +0800, Baoquan He wrote:
> > > Hi Mike,
> > >
> > > On 01/08/19 at 10:05am, Mike Rapoport wrote:
> > > > I'm not thrilled by duplicating this code (yet again).
On Thu, Jan 10, 2019 at 3:57 PM Mike Rapoport wrote:
>
> Hi Pingfan,
>
> On Wed, Jan 09, 2019 at 09:02:41PM +0800, Pingfan Liu wrote:
> > On Tue, Jan 8, 2019 at 11:49 PM Mike Rapoport wrote:
> > >
> > > On Tue, Jan 08, 2019 at 05:01:38PM +080
On Tue, Jan 8, 2019 at 11:49 PM Mike Rapoport wrote:
>
> On Tue, Jan 08, 2019 at 05:01:38PM +0800, Baoquan He wrote:
> > Hi Mike,
> >
> > On 01/08/19 at 10:05am, Mike Rapoport wrote:
> > > I'm not thrilled by duplicating this code (yet again).
> > > I liked the v3 of this patch [1] more, assuming
On Tue, Jan 8, 2019 at 10:34 PM Michal Hocko wrote:
>
> On Thu 20-12-18 10:19:34, Michal Hocko wrote:
> > On Thu 20-12-18 15:19:39, Pingfan Liu wrote:
> > > Hi Michal,
> > >
> > > WIth this patch applied on the old one, I got the following messa
On Wed, Jan 9, 2019 at 1:33 AM Dave Hansen wrote:
>
> On 1/7/19 10:13 PM, Pingfan Liu wrote:
> > On Tue, Jan 8, 2019 at 1:42 AM Dave Hansen wrote:
> >> Why is this 0x10 open-coded? Why is this needed *now*?
> >>
> >
> > Memory under 1MB
On Tue, Jan 8, 2019 at 6:06 PM Chao Fan wrote:
>
> On Mon, Jan 07, 2019 at 04:24:41PM +0800, Pingfan Liu wrote:
> >Background about the defect of the current bottom-up allocation style, take
> >the following scenario:
> > | unmovable
On Tue, Jan 8, 2019 at 1:11 AM Dave Hansen wrote:
>
>
> On 1/7/19 12:24 AM, Pingfan Liu wrote:
> > At present, memblock bottom-up allocation can help us against stamping over
> > movable node in very high probability.
>
> Is this what you are fixing? Making a &quo
On Tue, Jan 8, 2019 at 1:42 AM Dave Hansen wrote:
>
> On 1/7/19 12:24 AM, Pingfan Liu wrote:
> > There are two acheivements by this patch.
> > -1st. keep the subtree of pgtable away from movable node.
> > Background about the defect of the current bottom-u
On Tue, Jan 8, 2019 at 1:04 AM Dave Hansen wrote:
>
> On 1/7/19 12:24 AM, Pingfan Liu wrote:
> > Background about the defect of the current bottom-up allocation style, take
> > the following scenario:
> > | unmovable node | movable node |
On Mon, Jan 7, 2019 at 4:25 PM Pingfan Liu wrote:
>
> At present, memblock bottom-up allocation can help us against stamping over
> movable node in very high probability. But if the hotplug info has already
> been parsed, the memblock allocator can step around the movable node
I send out a series [RFC PATCH 0/4] x86_64/mm: remove bottom-up
allocation style by pushing forward the parsing of mem hotplug info (
https://lore.kernel.org/lkml/1546849485-27933-1-git-send-email-kernelf...@gmail.com/T/#t).
Please give comment if you are interested.
Thanks,
Pingfan
On Fri, Jan
en Brown
Cc: linux-kernel@vger.kernel.org
Pingfan Liu (4):
acpi: change the topo of acpi_table_upgrade()
x86/setup: parse acpi to get hotplug info before init_mem_mapping()
x86/mm: set allowed range for memblock allocator
x86/mm: remove bottom-up allocation style for x86_64
arch/arm64/kernel/setup.c
64 can directly set up the
subtree of pgtable at any place, hence the careful iteration in
memory_map_top_down() can be discard.
[1]: https://lore.kernel.org/patchwork/patch/1029376/
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin
from the case: start > end.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: linux-kernel@vger.kernel.org
---
,
the memblock allocator can work. Later in this series, the bottom-up
allocation style can be removed on x86_64.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Ra
-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: linux-kernel@vger.kernel.org
---
arch/arm64/kernel/setup.c | 2 +-
arch/x86/
no
memory below 896M can be reserved for crashkernel.
[1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
Signed-off-by: Pingfan Liu
Cc: Tang Chen
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Michal Hocko
Cc: Jonathan Corbet
Cc:
On Fri, Jan 4, 2019 at 5:43 PM Baoquan He wrote:
>
> On 01/04/19 at 04:39pm, Pingfan Liu wrote:
> > Customer reported a bug on a high end server with many pcie devices, where
> > kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> > though we still see
There is no early_trap_pf_init() implementation, hence removing this
useless declaration
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: linux-kernel@vger.kernel.org
---
arch/x86/include/asm/processor.h | 1 -
1 file
101 - 200 of 304 matches
Mail list logo
