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 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 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 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 >> --- >> arch/arm64/mm/numa.c | 40

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 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 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 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(+) > > The subject has arm64/numa,

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 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 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/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/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 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 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 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] 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/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] 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 wrote: > On

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 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/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 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 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 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 a/arch/arm64/mm/numa.c

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/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/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/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/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/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/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/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 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/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 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 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 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/8 12:45, Ganapatrao Kulkarni wrote: > On Wed, Jun 8, 2016 at 7:46 AM, Leizhen (ThunderTown) > wrote: >> >> >> On 2016/6/7 22:01, Ganapatrao Kulkarni wrote: >>> On Tue, Jun 7, 2016 at 6:27 PM, Leizhen (ThunderTown) >>> wrote: >>>>

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 22:01, Ganapatrao Kulkarni wrote: > On Tue, Jun 7, 2016 at 6:27 PM, Leizhen (ThunderTown) > wrote: >> >> >> 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

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 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 am wondering, if access to

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 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 init assumes cpu0/boot

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 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 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 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 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 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 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 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 >> from index=0, increase 1 until

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 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 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 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 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 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) > wrote: >> >> >> 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@ device

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 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 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 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 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 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 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 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 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/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] 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 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 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] 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] 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/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/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: [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: 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: 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/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: [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] 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)" > wrote: > >> Suppose: >> CONFIG_SPARSEMEM is opened. >> CONFIG_DMA_API_DEBUG or CONFIG_CMA is opened. >> >> Then virt_to_page or phys_

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

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 are adding extra logic to every single > instance of a

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: [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/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: 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 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 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] 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

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 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

<    1   2   3   4   5   >