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

2017-06-26 Thread Leizhen (ThunderTown)
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

2017-06-26 Thread Leizhen (ThunderTown)
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 wrote:

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

2017-06-07 Thread Leizhen (ThunderTown)
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 o

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

2017-09-28 Thread Leizhen (ThunderTown)
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 1/1] mm: only dispaly online cpus of the numa node

2017-10-08 Thread Leizhen (ThunderTown)
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 > /sys/devices/system/node/nodeX/

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

2017-08-08 Thread Leizhen (ThunderTown)
On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: > On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) > wrote: >> >> >> On 2017/7/26 19:08, Joerg Roedel wrote: >>> Hi Robin. >>> >>> On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote:

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

2017-08-08 Thread Leizhen (ThunderTown)
On 2017/8/9 11:24, Ganapatrao Kulkarni wrote: > On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown) > wrote: >> >> >> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: >>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) >>> wrote: >>>

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

2017-06-14 Thread Leizhen (ThunderTown)
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 >> only

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

2017-07-26 Thread Leizhen (ThunderTown)
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 1/1] Input: ims-pcu - fix typo in an error log

2017-11-23 Thread Leizhen (ThunderTown)
On 2017/11/24 15:17, Joe Perches wrote: > On Fri, 2017-11-24 at 14:59 +0800, Zhen Lei wrote: >> Tiny typo fixed in an error log. >> >> I found this when I backported the CVE-2017-16645 patch: >> ea04efee7635 ("Input: ims-psu - check if CDC union descriptor is sane") >> >> Signed-off-by: Zhen Lei

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

2016-10-17 Thread Leizhen (ThunderTown)
>> 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

2016-10-18 Thread Leizhen (ThunderTown)
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 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-08-21 Thread Leizhen (ThunderTown)
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

2016-08-22 Thread Leizhen (ThunderTown)
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 ind

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

2016-08-23 Thread Leizhen (ThunderTown)
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 2016/8

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

2016-08-23 Thread Leizhen (ThunderTown)
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 plan

<    1   2   3   4