Re: [PATCH 1/1] rtc: fix type information of rtc-proc

On 2015/11/11 18:54, Alexandre Belloni wrote: > On 11/11/2015 at 09:06:51 +0800, Leizhen (ThunderTown) wrote : >> Hi, all >> >> I'm sorry. Maybe I didn't describe clearly enough before. These words are >> finally >> shown to the end user. The end user may

Re: [PATCH 1/1] rtc: fix type information of rtc-proc

Hi, all I'm sorry. Maybe I didn't describe clearly enough before. These words are finally shown to the end user. The end user maybe not a programmer, abbreviation word is unsuitable. cat /proc/driver/rtc rtc_time: 00:47:43 rtc_date: 2015-11-11 alrm_time : 03:27:58

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

On 2015/9/28 17:44, Leizhen (ThunderTown) wrote: >> > >>> >> --drivers/char/Kconfig-- >>> >> if RTC_LIB=n >>> >> >>> >> config RTC >>> >> tristate "Enhanced Real Time

Re: [PATCH 1/1] of: to support binding numa node to root subnode(non-bus)

On 2015/8/24 21:25, Rob Herring wrote: +benh On Mon, Aug 24, 2015 at 7:30 AM, Zhen Lei thunder.leiz...@huawei.com wrote: If use of_platform_populate to scan dt-nodes and add devices, the subnode of root(such as /smmu), when being scanned and invoke You should have a bus as the sub-node

Re: [PATCH v2 0/1] of: to support binding numa node to specified device

Sorry, missed version number in title. On 2015/8/25 12:08, Zhen Lei wrote: > Changelog: > v1 -> v2: > In patch v1, binding numa node to specified device only take effect for > dt-nodes > directly of root. Patch v2 removed this limitation, we can binding numa node > to > any specified device in

Re: [PATCH v2 1/1] of: to support binding numa node to specified device in devicetree

Hi all, Can somebody take a few moments to review it? This patch is too small, only changed two lines. Thanks, Thunder. On 2015/8/25 12:08, Zhen Lei wrote: > For now, in function device_add, the new device will be forced to > inherit the numa node of its parent. But this will override the

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

On 2015/9/28 15:35, Arnd Bergmann wrote: > On Monday 28 September 2015 13:34:38 Zhen Lei wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 07d1811..25cec57 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -85,7 +85,7 @@ config ARM64 >> select

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

On 2015/9/28 16:42, Arnd Bergmann wrote: > On Monday 28 September 2015 16:29:57 Leizhen wrote: >> >> On 2015/9/28 15:35, Arnd Bergmann wrote: >>> On Monday 28 September 2015 13:34:38 Zhen Lei wrote: diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 07d1811..25cec57 100644

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

On 2015/9/28 15:40, Ard Biesheuvel wrote: > On 28 September 2015 at 06:34, Zhen Lei wrote: >> Now, ARM64 is also support EFI startup. We hope use EFI runtime services >> to get/set current time and date. >> >> RTC_LIB only controls some configs in

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

On 2016/6/7 21:58, Will Deacon wrote: > On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote: >> v3 -> v4: >> 1. Packed three patches of Kefeng Wang, patch6-8. >> 2. Add 6 new patches(9-15) to enhance the numa on arm64. >> >> v2 -> v3: >> 1. Adjust patch2 and patch5 according to Matthias

Re: [PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

On 2016/6/8 12:45, Ganapatrao Kulkarni wrote: > On Wed, Jun 8, 2016 at 7:46 AM, Leizhen (ThunderTown) > <thunder.leiz...@huawei.com> wrote: >> >> >> On 2016/6/7 22:01, Ganapatrao Kulkarni wrote: >>> On Tue, Jun 7, 2016 at 6:27 PM, Leizhen (ThunderTown)

Re: [PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

On 2016/6/7 22:01, Ganapatrao Kulkarni wrote: > On Tue, Jun 7, 2016 at 6:27 PM, Leizhen (ThunderTown) > <thunder.leiz...@huawei.com> wrote: >> >> >> On 2016/6/7 16:31, Ganapatrao Kulkarni wrote: >>> On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei <thunder.leiz.

Re: [PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

On 2016/6/7 16:31, Ganapatrao Kulkarni wrote: > On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei wrote: >> Some numa nodes may have no memory. For example: >> 1. cpu0 on node0 >> 2. cpu1 on node1 >> 3. device0 access the momory from node0 and node1 take the same time. > > i

Re: [PATCH v4 12/14] arm64/numa: remove some useless code

On 2016/6/7 16:28, Ganapatrao Kulkarni wrote: > On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei wrote: >> 1. Currently only cpu0 set on cpu_possible_mask and percpu areas have not >>been initialized. >> 2. No reason to limit cpu0 must belongs to node0. > > even smp

Re: [PATCH v2 2/5] of/numa: fix a memory@ node can only contains one memory block

On 2016/6/3 17:45, Will Deacon wrote: > On Thu, Jun 02, 2016 at 09:36:40AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/6/2 4:13, Rob Herring wrote: >>> I believe you still need this and not the one above. You only need it >>> within the loop if you return. Otherwise

Re: [PATCH v3 3/5] arm64/numa: add nid check for memory block

On 2016/6/3 17:52, Will Deacon wrote: > On Thu, Jun 02, 2016 at 10:28:09AM +0800, Zhen Lei wrote: >> Use the same tactic to cpu and numa-distance nodes. > > Sorry, I don't understand... :/ In function of_numa_parse_cpu_nodes: for_each_child_of_node(cpus, np) { ... r =

Re: [PATCH v3 5/5] arm64/numa: avoid inconsistent information to be printed

On 2016/6/3 17:55, Will Deacon wrote: > On Thu, Jun 02, 2016 at 10:28:11AM +0800, Zhen Lei wrote: >> numa_init(of_numa_init) may returned error because of numa configuration >> error. So "No NUMA configuration found" is inaccurate. In fact, specific >> configuration error information should be

Re: [PATCH 1/1] arm64: fix flush_cache_range

On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: >>>> On Tue, May 24, 2016 at 08:19:05PM +080

Re: [PATCH v2 5/5] arm64/numa: avoid inconsistent information to be printed

On 2016/5/31 19:27, Leizhen (ThunderTown) wrote: > > > On 2016/5/31 17:07, Matthias Brugger wrote: >> >> >> On 28/05/16 11:22, Zhen Lei wrote: >>> numa_init(of_numa_init) may returned error because of numa configuration >>> error. So "N

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On 2016/5/26 21:13, Rob Herring wrote: > On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >> For a normal memory@ devicetree node, its reg property can contains more >> memory blocks. >> >> Because we don't known how many memory blocks maybe contained, so we try >> from index=0,

Re: [PATCH 1/1] arm64: fix flush_cache_range

On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: >>>> On Tue, May 24, 2016 at 08:19:05PM +080

Re: [PATCH 3/3] arm64/numa: fix type info

On 2016/5/27 1:12, David Daney wrote: > The current patch to correct this problem is here: > > https://lkml.org/lkml/2016/5/24/679 > > Since v7 of the ACPI/NUMA patches are likely going to be added to linux-next > as soon as the current merge window ends, further simplifications of the >

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On 2016/5/27 12:20, Rob Herring wrote: > On Thu, May 26, 2016 at 10:36 PM, Leizhen (ThunderTown) > <thunder.leiz...@huawei.com> wrote: >> >> >> On 2016/5/26 21:13, Rob Herring wrote: >>> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >>>

Re: [PATCH v2 2/5] of/numa: fix a memory@ node can only contains one memory block

On 2016/6/2 4:13, Rob Herring wrote: > On Sat, May 28, 2016 at 4:22 AM, Zhen Lei wrote: >> For a normal memory@ devicetree node, its reg property can contains more >> memory blocks. >> >> Because we don't known how many memory blocks maybe contained, so we try >>

Re: [PATCH v2 5/5] arm64/numa: avoid inconsistent information to be printed

On 2016/5/31 17:07, Matthias Brugger wrote: > > > On 28/05/16 11:22, Zhen Lei wrote: >> numa_init(of_numa_init) may returned error because of numa configuration >> error. So "No NUMA configuration found" is inaccurate. In fact, specific >> configuration error information should be immediately

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

On 2016/6/20 14:39, Leizhen (ThunderTown) wrote: > > > On 2016/6/14 22:22, Catalin Marinas wrote: >> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote: >>> On 2016/6/7 21:58, Will Deacon wrote: >>>> On Tue, Jun 07, 2016 at 04:08:04PM +

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

On 2016/6/14 22:22, Catalin Marinas wrote: > On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/6/7 21:58, Will Deacon wrote: >>> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote: >>>> v3 -> v4: >>>> 1. Packed t

Re: [PATCH 2/2] PCI: generic: add description of property "interrupt-skip-mask"

On 2016/2/25 20:20, Mark Rutland wrote: > Hi, > > In future, please send the binding document first in a series, per point > 3 of Documentation/devicetree/bindings/submitting-patches.txt. It makes > review easier/faster. Thank you for your reminding. > > On Thu, Feb 25, 2016 at 07:53:28PM

Re: [PATCH 1/1] arm64/dma-mapping: remove an unnecessary conversion

On 2016/3/15 23:37, Catalin Marinas wrote: > On Tue, Mar 15, 2016 at 10:12:11AM +0800, Zhen Lei wrote: >> 1. In swiotlb_alloc_coherent, the branch of __get_free_pages. Directly >>return vaddr on success, and pass vaddr to free_pages on failure. >> 2. So, we can directly transparent pass

Re: Suspicious error for CMA stress test

On 2016/3/8 9:54, Leizhen (ThunderTown) wrote: > > > On 2016/3/8 2:42, Laura Abbott wrote: >> On 03/07/2016 12:16 AM, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2016/3/7 12:34, Joonsoo Kim wrote: >>>> On Fri, Mar 04, 2016 at 03:35:26PM +08

Re: [PATCH 1/1] dma-mapping: to avoid exception when cpu_addr is NULL

On 2016/3/8 6:59, Andrew Morton wrote: > On Mon, 7 Mar 2016 18:43:47 +0800 "Leizhen (ThunderTown)" > <thunder.leiz...@huawei.com> wrote: > >> Suppose: >> CONFIG_SPARSEMEM is opened. >> CONFIG_DMA_API_DEBUG or CONFIG_CMA is opened. >> >> Th

Re: [PATCH 1/1] arm64/dma-mapping: remove an unnecessary conversion

On 2016/3/16 9:56, Leizhen (ThunderTown) wrote: > > > On 2016/3/15 23:37, Catalin Marinas wrote: >> On Tue, Mar 15, 2016 at 10:12:11AM +0800, Zhen Lei wrote: >>> 1. In swiotlb_alloc_coherent, the branch of __get_free_pages. Directly >>>return vaddr on succ

Re: [PATCH 1/1] arm64/dma-mapping: remove an unnecessary conversion

On 2016/3/17 19:59, Catalin Marinas wrote: > On Thu, Mar 17, 2016 at 07:06:27PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/3/16 9:56, Leizhen (ThunderTown) wrote: >>> On 2016/3/15 23:37, Catalin Marinas wrote: >>>> On Tue, Mar 15, 2016 at 10:12:11AM +0800, Zh

Re: [PATCH 1/1] dma-mapping: to avoid exception when cpu_addr is NULL

On 2016/3/7 19:41, One Thousand Gnomes wrote: > On Mon, 7 Mar 2016 17:21:25 +0800 > Zhen Lei wrote: > >> Do this to keep consistent with kfree, which tolerate ptr is NULL. >> >> Signed-off-by: Zhen Lei > > This is inlined code so you

Re: [PATCH 1/1] dma-mapping: to avoid exception when cpu_addr is NULL

Suppose: CONFIG_SPARSEMEM is opened. CONFIG_DMA_API_DEBUG or CONFIG_CMA is opened. Then virt_to_page or phys_to_page will be called. Finally, in __pfn_to_page, __sec = __pfn_to_section(__pfn) is NULL. So access section->section_mem_map will trigger exception. - #define

Re: Suspicious error for CMA stress test

On 2016/3/8 2:42, Laura Abbott wrote: > On 03/07/2016 12:16 AM, Leizhen (ThunderTown) wrote: >> >> >> On 2016/3/7 12:34, Joonsoo Kim wrote: >>> On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote: >>>> On 2016/3/4 14:38, Joonsoo Kim wrote: >

Re: Suspicious error for CMA stress test

On 2016/3/7 12:34, Joonsoo Kim wrote: > On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote: >> On 2016/3/4 14:38, Joonsoo Kim wrote: >>> On Fri, Mar 04, 2016 at 02:05:09PM +0800, Hanjun Guo wrote: On 2016/3/4 12:32, Joonsoo Kim wrote: > On Fri, Mar 04, 2016 at 11:02:33AM +0900,

Re: [PATCH 1/1] arm64: fix flush_cache_range

On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 21:02, Catalin Marinas wrote: >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 19:37, Mark Rutland wrote: >>>> On Tue, May 24, 2016 at 07:16:37PM

Re: [PATCH 1/1] arm64: fix flush_cache_range

On 2016/5/24 19:37, Mark Rutland wrote: > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: >> When we ran mprotect04(a test case in LTP) infinitely, it would always >> failed after a few seconds. The case can be described briefly that: copy >> a empty function from code area into a new

Re: [PATCH 1/1] tty/serial: to support 8250 earlycon can be enabled independently

On 2016/5/16 23:40, Peter Hurley wrote: > On 05/16/2016 04:35 AM, Zhen Lei wrote: >> Sometimes, we may only use SSH to login, and build 8250 uart driver as a >> ko(insmod if needed). But the earlycon may still be necessary, because >> the kernel boot process may take a long time. It's not good

Re: [PATCH v5 03/14] arm64/numa: add nid check for memory block

On 2016/8/10 10:12, Hanjun Guo wrote: > On 2016/8/8 17:18, Zhen Lei wrote: >> Use the same tactic to cpu and numa-distance nodes. >> >> Signed-off-by: Zhen Lei >> --- >> arch/arm64/mm/numa.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/7/12 23:35, Catalin Marinas wrote: > On Mon, Jul 11, 2016 at 08:43:32PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/9 0:13, Catalin Marinas wrote: >>> On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote: >>>> On 2016/7/

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/7/8 21:54, Catalin Marinas wrote: > On Fri, Jul 08, 2016 at 11:36:57AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/7 23:37, Catalin Marinas wrote: >>> On Thu, Jul 07, 2016 at 08:09:04PM +0800, Zhen Lei wrote: >>>> At present, PG_dcache_clean is only

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/7/9 0:13, Catalin Marinas wrote: > On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/8 21:54, Catalin Marinas wrote: >>> On Fri, Jul 08, 2016 at 11:36:57AM +0800, Leizhen (ThunderTown) wrote: >>>> On 2016/7/7 23:37, Catal

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/7/7 23:37, Catalin Marinas wrote: > On Thu, Jul 07, 2016 at 08:09:04PM +0800, Zhen Lei wrote: >> At present, PG_dcache_clean is only cleared when the related huge page >> is about to be freed. But sometimes, there maybe a process is in charge >> to copy binary codes into a shared memory,

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/7/20 17:19, Catalin Marinas wrote: > On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote: >>>>>> On 2016/7/8 21:54, Catalin Marinas wrote: >>>>>>> 8< >>>>>>> diff -

Re: [PATCH v6 00/14] fix some type infos and bugs for arm64/of numa

Hi everybody: Is this patch series can be accepted or still need to be improved? It seems to have been a long time. Thanks, Zhen Lei On 2016/8/11 17:33, Zhen Lei wrote: > v5 -> v6: > Move memblk nid check from arch/arm64/mm/numa.c into drivers/of/of_numa.c, > because this check is arch

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/8/24 1:28, Catalin Marinas wrote: > On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/20 17:19, Catalin Marinas wrote: >>> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote: >>>>>>>>

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/8/24 18:30, Catalin Marinas wrote: > On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/24 1:28, Catalin Marinas wrote: >>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: >>>>

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/8/25 17:30, Catalin Marinas wrote: > On Thu, Aug 25, 2016 at 09:42:26AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/8/24 18:30, Catalin Marinas wrote: >>>>>>>>>>>> On 2016/7/8 21:54, Catalin Marinas wrote: >>>>>>>>

Re: [PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs

On 2016/8/31 1:55, Will Deacon wrote: > On Sat, Aug 27, 2016 at 06:44:39PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/26 23:35, Will Deacon wrote: >>> On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote: >>>> Update documentation. This l

Re: [PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed

On 2016/8/31 1:51, Will Deacon wrote: > On Sat, Aug 27, 2016 at 04:54:56PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/26 20:47, Will Deacon wrote: >>> On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote: >>>> numa_init(of_num

Re: [PATCH v8 00/16] fix some type infos and bugs for arm64/of numa

On 2016/9/8 19:01, Will Deacon wrote: > On Thu, Sep 01, 2016 at 02:54:51PM +0800, Zhen Lei wrote: >> v7 -> v8: >> Updated patches according to Will Deacon's review comments, thanks. >> >> The changed patches is: 3, 5, 8, 9, 10, 11, 12, 13, 15 >> Patch 3 requires an ack from Rob Herring. >> Patch

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

Hi, linux-mm folks: Can somebody help me to review this patch? I ran scripts/get_maintainer.pl -f mm/memblock.c and scripts/get_maintainer.pl -f mm/, but the results showed me that there is no maintainer. To understand this patch should also read patch 11. On 2016/9/1 14:55, Zhen Lei

Re: [RFC] Arm64 boot fail with numa enable in BIOS

On 2016/9/19 22:45, Will Deacon wrote: > On Mon, Sep 19, 2016 at 03:07:19PM +0100, Mark Rutland wrote: >> [adding LAKML, arm64 maintainers] > > I've also looped in Euler ThunderTown, since (a) he's at Huawei and is > assumedly testing this stuff and (b) he has a fairly big NUMA patch > series

Re: [PATCH v7 03/14] arm64/numa: add nid check for memory block

On 2016/8/26 20:39, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:42PM +0800, Zhen Lei wrote: >> Use the same tactic to cpu and numa-distance nodes. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/of/of_numa.c | 5 + >> 1 file changed, 5 insertions(+) > >

Re: [PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed

On 2016/8/26 20:47, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote: >> numa_init(of_numa_init) may returned error because of numa configuration >> error. So "No NUMA configuration found" is inaccurate. In fact, specific >> configuration error information should be

Re: [PATCH v7 08/14] arm64: numa: Use pr_fmt()

On 2016/8/26 20:54, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:47PM +0800, Zhen Lei wrote: >> From: Kefeng Wang >> >> Use pr_fmt to prefix kernel output, and remove duplicated msg >> of NUMA turned off. >> >> Signed-off-by: Kefeng Wang

Re: [PATCH v7 09/14] arm64/numa: support HAVE_SETUP_PER_CPU_AREA

On 2016/8/26 21:28, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:48PM +0800, Zhen Lei wrote: >> To make each percpu area allocated from its local numa node. Without this >> patch, all percpu areas will be allocated from the node which cpu0 belongs >> to. >> >> Signed-off-by: Zhen Lei

Re: [PATCH v7 10/14] arm64/numa: define numa_distance as array to simplify code

On 2016/8/26 23:29, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:49PM +0800, Zhen Lei wrote: >> 1. MAX_NUMNODES is base on CONFIG_NODES_SHIFT, the default value of the >>latter is very small now. >> 2. Suppose the default value of MAX_NUMNODES is enlarged to 64, so the >>size of

Re: [PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs

On 2016/8/26 23:35, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote: >> Update documentation. This limit is unneccessary. >> >> Signed-off-by: Zhen Lei >> Acked-by: Rob Herring >> --- >>

Re: [PATCH v7 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

On 2016/8/26 23:43, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:50PM +0800, Zhen Lei wrote: >> Some numa nodes may have no memory. For example: >> 1. cpu0 on node0 >> 2. cpu1 on node1 >> 3. device0 access the momory from node0 and node1 take the same time. >> >> So, we can not simply

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/8/24 1:28, Catalin Marinas wrote: > On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/20 17:19, Catalin Marinas wrote: >>> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote: >>>>>>>>

Re: [PATCH v7 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

On 2016/8/27 19:05, Leizhen (ThunderTown) wrote: > > > On 2016/8/26 23:43, Will Deacon wrote: >> On Wed, Aug 24, 2016 at 03:44:50PM +0800, Zhen Lei wrote: >>> Some numa nodes may have no memory. For example: >>> 1. cpu0 on node0 >>> 2. cpu1 on node1 &

Re: [PATCH v7 12/14] arm64/numa: remove the limitation that cpu0 must bind to node0

On 2016/8/26 23:49, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:51PM +0800, Zhen Lei wrote: >> 1. Currently only cpu0 set on cpu_possible_mask and percpu areas have not >>been initialized. This description refer to below: - for_each_possible_cpu(cpu) -

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

On 2016/8/23 19:30, Will Deacon wrote: > On Tue, Aug 23, 2016 at 07:19:01PM +0800, Leizhen (ThunderTown) wrote: >> He applied my patches, which I mentioned these days. > > [...] > >> I will update my patch series and resend it again. > > To be clear, you p

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

On 2016/8/22 22:28, Catalin Marinas wrote: > On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote: >> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote: >>> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni >>> wrote: On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang

Re: [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES

On 2016/10/27 2:36, Will Deacon wrote: > On Tue, Oct 25, 2016 at 10:59:18AM +0800, Zhen Lei wrote: >> Some numa nodes may have no memory. For example: >> 1) a node has no memory bank plugged. >> 2) a node has no memory bank slots. >> >> To ensure percpu variable areas and numa control blocks of

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

On 2016/10/26 17:31, Michal Hocko wrote: > On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote: >> >> >> On 2016/10/25 21:23, Michal Hocko wrote: >>> On Tue 25-10-16 10:59:17, Zhen Lei wrote: >>>> If HAVE_MEMORYLESS_NODES is selected, and some mem

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

On 2016/10/25 21:23, Michal Hocko wrote: > On Tue 25-10-16 10:59:17, Zhen Lei wrote: >> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are >> actually exist. The percpu variable areas and numa control blocks of that >> memoryless numa nodes need to be allocated from the

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

On 2016/10/27 15:22, Michal Hocko wrote: > On Thu 27-10-16 10:41:24, Leizhen (ThunderTown) wrote: >> >> >> On 2016/10/26 17:31, Michal Hocko wrote: >>> On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 20

Re: [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().

On 2016/10/27 1:00, David Daney wrote: > On 10/26/2016 06:43 AM, Robert Richter wrote: >> On 25.10.16 14:31:00, David Daney wrote: >>> From: David Daney >>> >>> On arm64 NUMA kernels we can pass "numa=off" on the command line to >>> disable NUMA. A side effect of this

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c >> index d3f151cfd4a1..8507703dabe4 100644 >> --- a/arch/arm64/kernel/smp.c >> +++ b/arch/arm64/kernel/smp.c >> @@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct >> acpi_madt_generic_interrupt *processor) >>

Re: [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

On 2016/10/18 16:39, Hanjun Guo wrote: > On 2016/10/17 22:56, Lorenzo Pieralisi wrote: >> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must >> bind to node0") removed the numa cpu<->node mapping restriction whereby >> logical cpu 0 always corresponds to numa node 0; removing

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

On 2016/10/11 18:16, Will Deacon wrote: > On Tue, Oct 11, 2016 at 09:44:20AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/9/1 14:55, Zhen Lei wrote: >>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are >>> actually exist. The percpu vari

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

On 2016/9/1 14:55, Zhen Lei wrote: > If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are > actually exist. The percpu variable areas and numa control blocks of that > memoryless numa nodes must be allocated from the nearest available node > to improve performance. > >

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

On 2017/3/23 19:42, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Keep these four variables type consistent with the paramters of function >> __alloc_and_insert_iova_range and the members of struct iova: >> >> 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

On 2017/3/23 21:01, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Reserve the first granule size memory(start at start_pfn) as boundary >> iova, to make sure that iovad->cached32_node can not be NULL in future. >> Meanwhile, changed the assignment of iovad->cached32_node from

Re: [PATCH 2/7] iommu/iova: cut down judgement times

On 2017/3/23 20:11, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Below judgement can only be satisfied at the last time, which produced 2N >> judgements(suppose N times failed, 0 or 1 time successed) in vain. >> >> if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) { >>

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

Because the problem of my email-server, all patches sent to Joerg Roedel <j...@8bytes.org> failed. So I repost this email again. On 2017/3/24 11:43, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 21:01, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

On 2017/3/24 10:27, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 19:42, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>> Keep these four variables type consistent with the paramters of function >>> __alloc_and_insert_iova_range and the members

Re: [PATCH 0/4] Optimise 64-bit IOVA allocations

On 2017/7/19 18:23, Robin Murphy wrote: > On 19/07/17 09:37, Ard Biesheuvel wrote: >> On 18 July 2017 at 17:57, Robin Murphy wrote: >>> Hi all, >>> >>> In the wake of the ARM SMMU optimisation efforts, it seems that certain >>> workloads (e.g. storage I/O with large

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/7/26 19:08, Joerg Roedel wrote: > Hi Robin. > > On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote: >> Hi all, >> >> In the wake of the ARM SMMU optimisation efforts, it seems that certain >> workloads (e.g. storage I/O with large scatterlists) probably remain quite >> heavily

Re: [PATCH 4/4] iommu/iova: Make dma_32bit_pfn implicit

On 2017/7/19 23:07, kbuild test robot wrote: > Hi Zhen, > > [auto build test WARNING on iommu/next] > [also build test WARNING on v4.13-rc1] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On 2017/6/28 17:32, Will Deacon wrote: > Hi Zhen Lei, > > Nate (CC'd), Robin and I have been working on something very similar to > this series, but this patch is different to what we had planned. More below. > > On Mon, Jun 26, 2017 at 09:38:46PM +0800, Zhen Lei wrote: >> Because all TLBI

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: > On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) > <thunder.leiz...@huawei.com> wrote: >> >> >> On 2017/7/26 19:08, Joerg Roedel wrote: >>> Hi Robin. >>> >>> On Fri, Jul 21,

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/9 11:24, Ganapatrao Kulkarni wrote: > On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown) > <thunder.leiz...@huawei.com> wrote: >> >> >> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: >>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown)

Re: [PATCH 0/5] arm-smmu: performance optimization

On 2017/8/17 22:36, Will Deacon wrote: > Thunder, Nate, Robin, > > On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote: >> I described the optimization more detail in patch 1 and 2, and patch 3-5 are >> the implementation on arm-smmu/arm-smmu-v3 of patch 2. >> >> Patch 1 is v2. In v1, I

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On 2017/8/22 23:41, Joerg Roedel wrote: > On Mon, Jun 26, 2017 at 09:38:46PM +0800, Zhen Lei wrote: >> -static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent) >> +static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent, int >> optimize) >> { >> if (queue_full(q)) >>

Re: [PATCH 1/1] iommu/arm-smmu-v3: replace writel with writel_relaxed in queue_inc_prod

On 2017/6/20 19:35, Robin Murphy wrote: > On 20/06/17 12:04, Zhen Lei wrote: >> This function is protected by spinlock, and the latter will do memory >> barrier implicitly. So that we can safely use writel_relaxed. In fact, the >> dmb operation will lengthen the time protected by lock, which

Re: [PATCH 1/1] iommu/arm-smmu-v3: replace writel with writel_relaxed in queue_inc_prod

On 2017/6/21 17:08, Will Deacon wrote: > On Wed, Jun 21, 2017 at 09:28:23AM +0800, Leizhen (ThunderTown) wrote: >> On 2017/6/20 19:35, Robin Murphy wrote: >>> On 20/06/17 12:04, Zhen Lei wrote: >>>> This function is protected by spinlock, and the latter will do memo

Re: [PATCH 1/1] iommu/arm-smmu-v3: replace writel with writel_relaxed in queue_inc_prod

On 2017/6/26 21:29, Leizhen (ThunderTown) wrote: > > > On 2017/6/21 17:08, Will Deacon wrote: >> On Wed, Jun 21, 2017 at 09:28:23AM +0800, Leizhen (ThunderTown) wrote: >>> On 2017/6/20 19:35, Robin Murphy wrote: >>>> On 20/06/17 12:04, Zhen Lei wro

[Question or BUG] [NUMA]: I feel puzzled at the function cpumask_of_node

When I executed numactl -H(print cpumask_of_node for each node), I got different result on X86 and ARM64. For each numa node, the former only displayed online CPUs, and the latter displayed all possible CPUs. Actually, all other ARCHs is the same to ARM64. So, my question is: Which case(online

Re: [Question or BUG] [NUMA]: I feel puzzled at the function cpumask_of_node

On 2017/6/8 22:12, Michal Hocko wrote: > [CC linux-api] > > On Wed 07-06-17 17:23:20, Leizhen (ThunderTown) wrote: >> When I executed numactl -H(print cpumask_of_node for each node), I got >> different result on X86 and ARM64. For each numa node, the former >>

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 2017/7/31 19:42, Robin Murphy wrote: > Hi Nate, > > On 29/07/17 04:57, Nate Watterson wrote: >> Hi Robin, >> I am seeing a crash when performing very basic testing on this series >> with a Mellanox CX4 NIC. I dug into the crash a bit, and think this >> patch is the culprit, but this rcache

Re: [PATCH v2 0/3] arm-smmu: performance optimization

On 2017/9/19 12:31, Nate Watterson wrote: > Hi Leizhen, > > On 9/12/2017 9:00 AM, Zhen Lei wrote: >> v1 -> v2: >> base on (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing") >> >> Zhen Lei (3): >>iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock >>

Re: [PATCH 1/1] mm: only dispaly online cpus of the numa node

On 2017/8/28 21:13, Michal Hocko wrote: > On Fri 25-08-17 18:34:33, Will Deacon wrote: >> On Thu, Aug 24, 2017 at 10:32:26AM +0200, Michal Hocko wrote: >>> It seems this has slipped through cracks. Let's CC arm64 guys >>> >>> On Tue 20-06-17 20:43:28, Zhen Lei wrote: When I executed numactl

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 2017/8/4 3:41, Nate Watterson wrote: > Hi Robin, > > On 7/31/2017 7:42 AM, Robin Murphy wrote: >> Hi Nate, >> >> On 29/07/17 04:57, Nate Watterson wrote: >>> Hi Robin, >>> I am seeing a crash when performing very basic testing on this series >>> with a Mellanox CX4 NIC. I dug into the crash

Re: [PATCH v2 1/1] mm: only dispaly online cpus of the numa node

On 2017/10/3 21:56, Michal Hocko wrote: > On Tue 03-10-17 14:47:26, Will Deacon wrote: >> On Mon, Oct 02, 2017 at 02:54:46PM -0700, Andrew Morton wrote: >>> On Mon, 2 Oct 2017 11:38:07 +0100 Will Deacon wrote: >>> > When I executed numactl -H(which read >

Re: [PATCH v2 2/3] iommu/arm-smmu-v3: add support for unmap an iova range with only one tlb sync

On 2017/10/18 21:00, Will Deacon wrote: > On Tue, Sep 12, 2017 at 09:00:37PM +0800, Zhen Lei wrote: >> This patch is base on: >> (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing") >> >> Because iotlb_sync is moved out of ".unmap = arm_smmu_unmap", some interval >> ".unmap"

  1   2   3   4   5   >