Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-07 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-07 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-07 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-06 Thread Pingfan Liu
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.

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-06 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-06 Thread Pingfan Liu
[...] > 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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-05 Thread Pingfan Liu
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,

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-05 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-05 Thread Pingfan Liu
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,

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-04 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-04 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-04 Thread Pingfan Liu
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 A

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-04 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-04 Thread Pingfan Liu
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

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-04 Thread Pingfan Liu
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, >

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-03 Thread Pingfan Liu
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 > >a

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-03 Thread Pingfan Liu
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 > >

[PATCH] mm/alloc: fallback to first node if the wanted node offline

2018-12-03 Thread Pingfan Liu
e-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: Vlastimil

Re: [BUG -next 20181008] list corruption with "mm/slub: remove useless condition in deactivate_slab"

2018-10-18 Thread Pingfan Liu
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

Re: [BUG -next 20181008] list corruption with "mm/slub: remove useless condition in deactivate_slab"

2018-10-16 Thread Pingfan Liu
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 enabled on

Re: [BUG -next 20181008] list corruption with "mm/slub: remove useless condition in deactivate_slab"

2018-10-14 Thread Pingfan Liu
own 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 used to

Re: [PATCH 1/3] drivers/base: move device_shutdown() to base/power

2018-09-18 Thread Pingfan Liu
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

Re: [REGRESSION] Errors at reboot after 722e5f2b1eec

2018-09-13 Thread Pingfan Liu
On Thu, Sep 13, 2018 at 10:15 PM Rafael J. Wysocki wrote: > > On Thursday, September 13, 2018 12:03:36 PM CEST James Wang wrote: > > This is a multi-part message in MIME format. > > --F5519E624D0AD1E3F7DDA019 > > Content-Type: text/plain; charset=utf-8 > > Content-Transfer-Encoding:

Re: [REGRESSION] Errors at reboot after 722e5f2b1eec

2018-09-12 Thread Pingfan Liu
On Tue, Sep 11, 2018 at 5:37 PM Greg Kroah-Hartman wrote: > > On Tue, Sep 11, 2018 at 10:17:44AM +0200, Takashi Iwai wrote: > > [ seems like my previous post didn't go out properly; if you have > > already received it, please discard this one ] > > Sorry, I got it, it's just in my large queue

Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage

2018-09-10 Thread Pingfan Liu
On Mon, Sep 10, 2018 at 7:33 AM Baoquan He wrote: > > Hi Pingfan, > > On 09/06/18 at 10:36am, Pingfan Liu wrote: > > commit 747ff6265db4 ("x86/boot/KASLR: Skip specified number of 1GB huge > > pages when doing physical randomization (KASLR)") and commit > >

Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage

2018-09-05 Thread Pingfan Liu
On Thu, Sep 6, 2018 at 12:07 PM Chao Fan wrote: > > On Thu, Sep 06, 2018 at 10:36:19AM +0800, Pingfan Liu wrote: > > Hi Pingfan, > > >commit 747ff6265db4 ("x86/boot/KASLR: Skip specified number of 1GB huge > >pages when doing physical randomization (KASLR)")

[PATCH 1/3] x86/boot/KASLR: change the prototypes of process_efi_entries/process_e820_entries

2018-09-05 Thread Pingfan Liu
Changing the prototypes of process_efi_entries/process_e820_entries in order to reuse the mem entries' iteration (used in patch 3/3). Signed-off-by: Pingfan Liu Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: "Kirill A. Shutemov" Cc: Baoquan He Cc: Chao F

[PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage

2018-09-05 Thread Pingfan Liu
then Y=3, assuming X=2, the improvement equals: 50%( 6/(6-2) - 1); assuming X=1, the improvement will be: 20% (6/(6-1) - 1) Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: "Kirill A. Shutemov" Cc: Baoquan He Cc: Chao Fan (authored:1/16=6%) Cc: x...@kernel.org

[PATCH 2/3] x86/boot/KASLR: change the prototype of process_mem_region() to meet the align requirement

2018-09-05 Thread Pingfan Liu
-by: Pingfan Liu Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: "Kirill A. Shutemov" Cc: Baoquan He Cc: Chao Fan (authored:1/16=6%) Cc: x...@kernel.org --- arch/x86/boot/compressed/kaslr.c | 36 1 file changed, 24 inserti

[PATCH 3/3] x86/boot/KASLR: enhance randomness when using GiB hugepage

2018-09-05 Thread Pingfan Liu
then Y=3, assuming X=2, the improvement equals: 50%( 6/(6-2) - 1); assuming X=1, the improvement will be: 20% (6/(6-1) - 1) Signed-off-by: Pingfan Liu Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: "Kirill A. Shutemov" Cc: Baoquan He Cc: Chao Fan (authored:1/16

[PATCH 2/3] PM/shutdown: device_shutdown() uses the order info in dpm_list instead of devices_kset

2018-08-20 Thread Pingfan Liu
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 +

[PATCH 3/3] drivers/base: clean up unused devices_kset_move_*() functions

2018-08-20 Thread Pingfan Liu
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

[PATCH 1/3] drivers/base: move device_shutdown() to base/power

2018-08-20 Thread Pingfan Liu
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

[PATCH 0/3] PM: simplify the code logic on device_shutdown and suspend

2018-08-20 Thread Pingfan Liu
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

[PATCH] drivers/base: stop new probing during shutdown

2018-07-18 Thread Pingfan Liu
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

Re: [PATCH] driver core: Drop devices_kset_move_last() call from really_probe()

2018-07-10 Thread Pingfan Liu
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 -

Re: question about the limited interrupt vector resource on a single cpu

2018-06-06 Thread Pingfan Liu
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

Re: question about the limited interrupt vector resource on a single cpu

2018-06-06 Thread Pingfan Liu
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 i

question about the limited interrupt vector resource on a single cpu

2018-06-06 Thread Pingfan Liu
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