revent the new probing request. With this
logic, device_shutdown() is more similar to dpm_prepare().
Cc: Rafael J. Wysocki
Cc: Greg Kroah-Hartman
Signed-off-by: Pingfan Liu
---
drivers/base/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
On Tue, Dec 4, 2018 at 4:56 PM Michal Hocko wrote:
>
> On Tue 04-12-18 16:20:32, Pingfan Liu wrote:
> > On Tue, Dec 4, 2018 at 3:22 PM Michal Hocko wrote:
> > >
> > > On Tue 04-12-18 11:05:57, Pingfan Liu wrote:
> > > > During my test on some AMD ma
On Tue, Dec 4, 2018 at 3:16 PM Pingfan Liu wrote:
>
> On Tue, Dec 4, 2018 at 11:53 AM David Rientjes wrote:
> >
> > On Tue, 4 Dec 2018, Pingfan Liu wrote:
> >
> > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > > index 76f8db0..8324
On Tue, Dec 4, 2018 at 5:09 PM Wei Yang wrote:
>
> On Tue, Dec 04, 2018 at 04:52:52PM +0800, Pingfan Liu wrote:
> >On Tue, Dec 4, 2018 at 4:34 PM Wei Yang wrote:
> >>
> >> On Tue, Dec 04, 2018 at 03:20:13PM +0800, Pingfan Liu wrote:
> >> >On T
On Wed, Dec 5, 2018 at 5:21 PM Michal Hocko wrote:
>
> On Wed 05-12-18 13:38:17, Pingfan Liu wrote:
> > On Tue, Dec 4, 2018 at 4:56 PM Michal Hocko wrote:
> > >
> > > On Tue 04-12-18 16:20:32, Pingfan Liu wrote:
> > > > On Tue, Dec 4, 2018 at 3:22 PM M
On Wed, Dec 5, 2018 at 5:40 PM Vlastimil Babka wrote:
>
> On 12/5/18 10:29 AM, Pingfan Liu wrote:
> >> [0.007418] Early memory node ranges
> >> [0.007419] node 1: [mem 0x1000-0x0008efff]
> >> [0.007420] node 1: [mem 0x00
On Wed, Dec 5, 2018 at 5:43 PM Michal Hocko wrote:
>
> On Wed 05-12-18 17:29:31, Pingfan Liu wrote:
> > On Wed, Dec 5, 2018 at 5:21 PM Michal Hocko wrote:
> > >
> > > On Wed 05-12-18 13:38:17, Pingfan Liu wrote:
> > > > On Tue, Dec 4, 2018 at 4:56 PM M
[...]
> THanks for pointing this out. It made my life easier. So It think the
> bug is that we call init_memory_less_node from this path. I suspect
> numa_register_memblks is the right place to do this. So I admit I
> am not 100% sure but could you give this a try please?
>
Sure.
> diff --git a/ar
On Thu, Dec 6, 2018 at 6:03 PM Pingfan Liu wrote:
>
> [...]
> > THanks for pointing this out. It made my life easier. So It think the
> > bug is that we call init_memory_less_node from this path. I suspect
> > numa_register_memblks is the right place to do this. So I admi
On Thu, Dec 6, 2018 at 8:11 PM Michal Hocko wrote:
>
> On Thu 06-12-18 18:44:03, Pingfan Liu wrote:
> > On Thu, Dec 6, 2018 at 6:03 PM Pingfan Liu wrote:
> [...]
> > > Which commit is this patch applied on? I can not apply it on latest linux
> > > tree.
>
On Fri, Dec 7, 2018 at 3:53 PM Michal Hocko wrote:
>
> On Fri 07-12-18 10:56:51, Pingfan Liu wrote:
> [...]
> > In a short word, the fix method should consider about the two factors:
> > semantic of online-node and the effect on all archs
>
> I am pretty sure
On Fri, Dec 7, 2018 at 7:30 PM Michal Hocko wrote:
>
[...]
> On Fri 07-12-18 17:40:09, Pingfan Liu wrote:
> > On Fri, Dec 7, 2018 at 3:53 PM Michal Hocko wrote:
> > >
> > > On Fri 07-12-18 10:56:51, Pingfan Liu wrote:
> > > [...]
> > > > In a s
On Fri, Dec 7, 2018 at 10:22 PM Michal Hocko wrote:
>
> On Fri 07-12-18 21:20:17, Pingfan Liu wrote:
> [...]
> > Hi Michal,
> >
> > As I mentioned in my previous email, I have manually apply the patch,
> > and the patch can not work for normal bootup.
>
> I
On Fri, Dec 7, 2018 at 11:56 PM Michal Hocko wrote:
>
> On Fri 07-12-18 22:27:13, Pingfan Liu wrote:
> [...]
> > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > index 1308f54..4dc497d 100644
> > --- a/arch/x86/mm/numa.c
> > +++ b/arch/x86/mm/numa.c
>
device-specific _PXM node values"
This bug is covered and not triggered on my test AMD machine.
But it should still exist since dev->numa_node info can be set by other
method on other archs when using nr_cpus param
Signed-off-by: Pingfan Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Vlast
On Tue, Dec 4, 2018 at 11:53 AM David Rientjes wrote:
>
> On Tue, 4 Dec 2018, Pingfan Liu wrote:
>
> > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > index 76f8db0..8324953 100644
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> >
On Tue, Dec 4, 2018 at 2:54 PM Wei Yang wrote:
>
> On Tue, Dec 04, 2018 at 11:05:57AM +0800, Pingfan Liu wrote:
> >During my test on some AMD machine, with kexec -l nr_cpus=x option, the
> >kernel failed to bootup, because some node's data struct can not be
>
On Tue, Dec 4, 2018 at 3:22 PM Michal Hocko wrote:
>
> On Tue 04-12-18 11:05:57, Pingfan Liu wrote:
> > During my test on some AMD machine, with kexec -l nr_cpus=x option, the
> > kernel failed to bootup, because some node's data struct can not be
> > allocated,
&g
On Tue, Dec 4, 2018 at 4:34 PM Wei Yang wrote:
>
> On Tue, Dec 04, 2018 at 03:20:13PM +0800, Pingfan Liu wrote:
> >On Tue, Dec 4, 2018 at 2:54 PM Wei Yang wrote:
> >>
> >> On Tue, Dec 04, 2018 at 11:05:57AM +0800, Pingfan Liu wrote:
> >> >During my test
On Tue, Dec 4, 2018 at 4:40 PM Wei Yang wrote:
>
> On Tue, Dec 04, 2018 at 04:20:32PM +0800, Pingfan Liu wrote:
> >On Tue, Dec 4, 2018 at 3:22 PM Michal Hocko wrote:
> >>
> >> On Tue 04-12-18 11:05:57, Pingfan Liu wrote:
> >> > During my test on some A
r core: correct device's shutdown order)
> Link:
> https://lore.kernel.org/lkml/CAFgQCTt7VfqM=uycnvnfxrsw8z6cutai3huwr4_xpac03sg...@mail.gmail.com/
> Reported-by: Pingfan Liu
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/base/dd.c |8
requently.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: linux-kernel@vger.kernel.org
---
Pingfan Liu (3):
drivers/base: move device_shutdown() to base/power
PM/shutdown: device_shutdown() uses the order info in dpm_list instead
of devices_kset
drivers/base: clean up un
kernel.org
Signed-off-by: Pingfan Liu
---
drivers/base/core.c | 70 ---
drivers/base/power/Makefile | 1 +
drivers/base/power/shutdown.c | 76 +++
3 files changed, 77 insertions(+), 70 deletions(-)
create m
Now, shutdown seq is unified with PM, and there is no need to maintain the
"parent <- child" or "supplier <- consumer" order in devices_kset any more,
hence removing the corresponding routines
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: linux-kernel@vg
requently.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Pingfan Liu
---
drivers/base/power/main.c | 119 --
drivers/base/power/power.h| 25 +
drivers/base/power/shutdown.c | 63 +
/019571.html
Signed-off-by: Pingfan Liu
Cc: Dave Young
Cc: Andrew Morton
Cc: Baoquan He
Cc: ying...@kernel.org,
Cc: vgo...@redhat.com
Cc: ke...@lists.infradead.org
---
arch/x86/kernel/setup.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/setup.c b
On Mon, Dec 10, 2018 at 8:37 PM Michal Hocko wrote:
>
[...]
>
> In other words. Does the following work? I am sorry to wildguess this
> way but I am not able to recreate your setups to play with this myself.
>
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 1308f5408bf7..d51643e10d0
On Tue, Dec 11, 2018 at 5:44 PM Michal Hocko wrote:
>
> On Tue 11-12-18 16:05:58, Pingfan Liu wrote:
> > On Mon, Dec 10, 2018 at 8:37 PM Michal Hocko wrote:
> > >
> > > On Fri 07-12-18 16:56:27, Michal Hocko wrote:
> > > > On Fri 07-12-18 22:27:13, Pingf
On Wed, Dec 12, 2018 at 7:53 PM Michal Hocko wrote:
>
> On Wed 12-12-18 16:31:35, Pingfan Liu wrote:
> > On Mon, Dec 10, 2018 at 8:37 PM Michal Hocko wrote:
> > >
> > [...]
> > >
> > > In other words. Does the following work? I am sorry to wildguess
On Thu, Dec 13, 2018 at 4:37 PM Pingfan Liu wrote:
>
> On Wed, Dec 12, 2018 at 7:53 PM Michal Hocko wrote:
> >
> > On Wed 12-12-18 16:31:35, Pingfan Liu wrote:
> > > On Mon, Dec 10, 2018 at 8:37 PM Michal Hocko wrote:
> > > >
> > > [...]
> &g
Hi Baoquan,
Thanks for your kindly review. I will update the commit log to explain
the scenario.
Best regards,
Pingfan
On Wed, Dec 12, 2018 at 5:01 PM Baoquan He wrote:
>
> Hi Pingfan,
>
> Thanks for fixing this.
>
> On 12/12/18 at 04:19pm, Pingfan Liu wrote:
> >
, the old tool also fail since there is 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: Dave Young
Cc: Andrew Morton
Cc: Baoquan He
Cc: ying...@kernel.org,
Cc: vgo...@redhat.com
Cc: ke...
Hi Michal,
WIth this patch applied on the old one, I got the following message.
Please get it from attachment.
Thanks,
Pingfan
On Mon, Dec 17, 2018 at 9:29 PM Michal Hocko wrote:
>
> On Thu 13-12-18 17:04:01, Pingfan Liu wrote:
> [...]
> > > > @@ -592,6 +600,10
On Mon, Dec 10, 2018 at 12:00 PM Pingfan Liu wrote:
>
> On Fri, Dec 7, 2018 at 11:56 PM Michal Hocko wrote:
> >
> > On Fri 07-12-18 22:27:13, Pingfan Liu wrote:
> > [...]
> > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > > index 1308f54..4dc
On Mon, Dec 10, 2018 at 8:37 PM Michal Hocko wrote:
>
> On Fri 07-12-18 16:56:27, Michal Hocko wrote:
> > On Fri 07-12-18 22:27:13, Pingfan Liu wrote:
> > [...]
> > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > > index 1308f54..4dc497d 1
see:
https://lore.kernel.org/patchwork/comment/1208479/
https://lore.kernel.org/patchwork/comment/1210452/
It has already cost a little long time to find a solution, cc x86 and ppc
mailing list
and hope their maintainers to give some suggestion to speed up the final
solution.
Pingfan Liu (3):
mm/n
building of zonelist for
offline nodes.
Signed-off-by: Pingfan Liu
Cc: linuxppc-...@lists.ozlabs.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Mike Rapoport
Cc: Bjorn Helgaas
Cc: Jonathan Cameron
Cc: David Rientjes
Cc
chwork/patch/1020838/
Signed-off-by: Pingfan Liu
Cc: linuxppc-...@lists.ozlabs.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Mike Rapoport
Cc: Bjorn Helgaas
Cc: Jonathan Cameron
Cc: David Rientjes
Cc: Thomas Gleixner
Cc
ther
method on other archs when using nr_cpus param
Signed-off-by: Pingfan Liu
Cc: linuxppc-...@lists.ozlabs.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Mike Rapoport
Cc: Bjorn Helgaas
Cc: Jonathan Cameron
Cc: David Rientjes
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)
> > */
> > static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
> >
On Thu, Dec 20, 2018 at 8:44 PM Michal Hocko wrote:
>
> 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:
> > > [...]
> > > > @@ -45
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 much
, the old tool also fail since there is 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:
: 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/
,
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
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
---
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
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
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 4
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 by
&g
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 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-up alloca
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 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 Mon, Dec 31, 2018 at 4:46 PM Mike Rapoport wrote:
>
> On Fri, Dec 28, 2018 at 11:00:02AM +0800, 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
> >
On Mon, Dec 31, 2018 at 4:40 PM Mike Rapoport wrote:
>
> On Fri, Dec 28, 2018 at 11:00:01AM +0800, Pingfan Liu wrote:
> > The bottom-up allocation style is introduced to cope with movable_node,
> > where the limit inferior of allocation starts from kernel's end, due to
&
On Wed, Jan 2, 2019 at 6:18 PM Baoquan He wrote:
>
> On 01/02/19 at 11:27am, Mike Rapoport wrote:
> > On Wed, Jan 02, 2019 at 02:47:34PM +0800, Pingfan Liu wrote:
> > > On Mon, Dec 31, 2018 at 4:40 PM Mike Rapoport wrote:
> > > >
> > > > On Fri,
, the old tool also fail since there is 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: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Michal Hock
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
On Wed, Dec 26, 2018 at 9:58 AM Dave Young wrote:
>
> On 12/14/18 at 12:07pm, 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 much
On Wed, Dec 26, 2018 at 9:47 AM Dave Young wrote:
>
> On 12/14/18 at 12:07pm, 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 much
7;kexec -c' prefers to reuse this style to alloc mem at lower address,
since if the reserved region is beyond 4G, then it requires extra mem
(default is 16M) for swiotlb.
Signed-off-by: Pingfan Liu
Cc: Tang Chen
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Andrew Morton
Cc: Mike Rapop
ux-kernel@vger.kernel.org
Pingfan Liu (2):
mm/memblock: extend the limit inferior of bottom-up after parsing
hotplug attr
x86/kdump: bugfix, make the behavior of crashkernel=X consistent with
kaslr
arch/x86/kernel/setup.c | 9 +---
drivers/acpi/numa.c | 4
include/li
, the old tool also fail since there is 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:
Hi heiko,
On Mon, Oct 15, 2018 at 1:54 PM Pingfan Liu wrote:
>
> On Tue, Oct 9, 2018 at 2:35 PM Heiko Carstens
> wrote:
> >
> > Hello,
> >
> > with linux-next for 20181008 I can reliably crash my system with lot's of
> > debugging options enabl
ect down to this commit:
>
> fde06e07750477f049f12d7d471ffa505338a3e7 is the first bad commit
> commit fde06e07750477f049f12d7d471ffa505338a3e7
> Author: Pingfan Liu
> Date: Thu Oct 4 07:43:01 2018 +1000
>
> mm/slub: remove useless condition in deactivate_slab
>
> The var l should be us
On Tue, Oct 16, 2018 at 3:36 PM Heiko Carstens
wrote:
>
> On Tue, Oct 16, 2018 at 02:29:28PM +0800, Pingfan Liu wrote:
> > > I think it is caused by the uinon page->lru and page->next. It can be
> > > fixed by:
> > > diff --git a/include/linux/slub_def.h
On Fri, Sep 14, 2018 at 5:10 PM Rafael J. Wysocki wrote:
>
> On Monday, August 20, 2018 11:18:35 AM CEST Pingfan Liu wrote:
> > Consider the shutdown as a system state transition, i.e. something like
> > suspend, hibernate, hence move it under the base/power. (This is a first
For x86, there is around 200 vectors left for external device on a
single logic cpu.
Is there any case that we exhaust them in real world, and is it worth to fix?
Thanks,
Pingfan
On Wed, Jun 6, 2018 at 5:15 PM, Thomas Gleixner wrote:
> On Wed, 6 Jun 2018, Pingfan Liu wrote:
>
>> For x86, there is around 200 vectors left for external device on a
>> single logic cpu.
>>
>> Is there any case that we exhaust them in real world, and is it w
On Wed, Jun 6, 2018 at 5:34 PM, Thomas Gleixner wrote:
> On Wed, 6 Jun 2018, Pingfan Liu wrote:
>
>> On Wed, Jun 6, 2018 at 5:15 PM, Thomas Gleixner wrote:
>> > On Wed, 6 Jun 2018, Pingfan Liu wrote:
>> >
>> >> For x86, there is around 200 vectors left f
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
memblock_x86_reserve_range_setup_data(vo
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
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
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 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 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
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:
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 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 the
>
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*firs
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 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
>
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 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 boot
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 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 allocator does n
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' with
It is useless to keep debug info in purgatory. And discarding them saves
about 200K space.
Original:
259080 kexec-purgatory.o
Stripped:
29152 kexec-purgatory.o
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Han
On Fri, Jul 31, 2020 at 7:11 AM Nick Desaulniers
wrote:
>
> On Thu, Jul 30, 2020 at 1:27 AM Pingfan Liu wrote:
> >
> > It is useless to keep debug info in purgatory. And discarding them saves
> > about 200K space.
> >
> > Original:
> > 259080 ke
On Sat, Aug 1, 2020 at 2:18 AM Nick Desaulniers wrote:
>
> On Fri, Jul 31, 2020 at 2:36 AM Pingfan Liu wrote:
> >
> > On Fri, Jul 31, 2020 at 7:11 AM Nick Desaulniers
> > wrote:
> > >
> > > On Thu, Jul 30, 2020 at 1:27 AM Pingfan Liu wrote:
> >
useless in purgatory.ro. And discarding them can save about
200K space.
Original:
259080 kexec-purgatory.o
Stripped debug info:
29152 kexec-purgatory.o
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Hans de Goede
Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had better
do the check during built time, and associate these related code together.
Signed-off-by: Pingfan Liu
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Mark Rutland
On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier wrote:
>
> On 2020-12-08 09:21, Pingfan Liu wrote:
> > Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
> > better
> > do the check during built time, and associate these related code
> > together.
&
On Tue, Dec 8, 2020 at 5:51 PM Marc Zyngier wrote:
>
> On 2020-12-08 09:43, Pingfan Liu wrote:
> > On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier wrote:
> >>
> >> On 2020-12-08 09:21, Pingfan Liu wrote:
> >> > Although there is a runtime WARN_ON() w
Hi Pavel,
After going through this series, I think if this can be done by using
identity map through ttbr0.
Then the processes may be neat (I hope so):
-1. set up identity map in machine_kexec_post_load(), instead of
copying linear map.
-2. Also past this temporary identity map to arm64_relocate_
coli"
Cc: Petr Mladek
Cc: ke...@lists.infradead.org
To: linux-kernel@vger.kernel.org
Pingfan Liu (3):
x86/irq: account the unused irq
kernel/watchdog: make watchdog_touch_ts more accurate by using
nanosecond
kernel/watchdog: use soft lockup to detect irq flood
arch/x86/kernel/irq.c | 1
Accounting the unused irq in order to count it if irq flood.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Jisheng Zhang
Cc: "Peter Zijlstra (Intel)"
Cc: Vlastimil Babka
Cc: Andrew Morton
Cc: "Guilherme G. Piccoli"
Cc: Petr Mladek
Cc: ke...@lists.infradead.
://lore.kernel.org/lkml/87tuueftou@nanos.tec.linutronix.de/
[2]:
https://lore.kernel.org/linux-pci/20181018183721.27467-1-gpicc...@canonical.com/
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Jisheng Zhang
Cc: "Peter Zijlstra (Intel)"
Cc: Vlastimil Babka
Cc: Andrew Morton
Cc: &q
1 - 100 of 265 matches
Mail list logo
