From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757245AbcLPGjv (ORCPT ); Fri, 16 Dec 2016 01:39:51 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:53153 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754045AbcLPGjn (ORCPT ); Fri, 16 Dec 2016 01:39:43 -0500 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.249.26 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 16 Dec 2016 15:39:40 +0900 From: Minchan Kim To: Andreas Schwab CC: , , , , Jason Evans Subject: Re: jemalloc testsuite stalls in memset Message-ID: <20161216063940.GA1334@bbox> References: <20161214235031.GA2912@bbox> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/12/16 15:39:40, Serialize by Router on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/12/16 15:39:40, Serialize complete at 2016/12/16 15:39:40 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Thu, Dec 15, 2016 at 10:24:47AM +0100, Andreas Schwab wrote: > On Dez 15 2016, Minchan Kim wrote: > > > You mean program itself access the address(ie, 0xffffb7400000) is hang > > while access the address from the debugger is OK? > > Yes. > > > Can you reproduce it easily? > > 100% > > > Did you test it in real machine or qemu on x86? > > Both real and kvm. > > > Could you show me how I can reproduce it? > > Just run make check. > > > I want to test it in x86 machine, first of all. > > Unfortunately, I don't have any aarch64 platform now so maybe I have to > > run it on qemu on x86 until I can set up aarch64 platform if it is reproducible > > on real machine only. > > > >> > >> The kernel has been configured with transparent hugepages. > >> > >> CONFIG_TRANSPARENT_HUGEPAGE=y > >> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y > >> # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set > >> CONFIG_TRANSPARENT_HUGE_PAGECACHE=y > > > > What's the exact kernel version? > > Anything >= your commit. Thanks for the info. I cannot setup testing enviroment but when I read code, it seems we need pmd_wrprotect for non-hardware dirty architecture. Below helps? diff --git a/mm/huge_memory.c b/mm/huge_memory.c index e10a4fe..dc37c9a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1611,6 +1611,7 @@ int madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, tlb->fullmm); orig_pmd = pmd_mkold(orig_pmd); orig_pmd = pmd_mkclean(orig_pmd); + orig_pmd = pmd_wrprotect(orig_pmd); set_pmd_at(mm, addr, pmd, orig_pmd); tlb_remove_pmd_tlb_entry(tlb, pmd, addr); From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 3CE986B0038 for ; Fri, 16 Dec 2016 01:39:44 -0500 (EST) Received: by mail-pf0-f197.google.com with SMTP id 83so107984425pfx.1 for ; Thu, 15 Dec 2016 22:39:44 -0800 (PST) Received: from lgeamrelo12.lge.com (LGEAMRELO12.lge.com. [156.147.23.52]) by mx.google.com with ESMTP id 189si6208789pgi.82.2016.12.15.22.39.42 for ; Thu, 15 Dec 2016 22:39:43 -0800 (PST) Date: Fri, 16 Dec 2016 15:39:40 +0900 From: Minchan Kim Subject: Re: jemalloc testsuite stalls in memset Message-ID: <20161216063940.GA1334@bbox> References: <20161214235031.GA2912@bbox> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: Andreas Schwab Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mbrugger@suse.de, linux-mm@kvack.org, Jason Evans Hello, On Thu, Dec 15, 2016 at 10:24:47AM +0100, Andreas Schwab wrote: > On Dez 15 2016, Minchan Kim wrote: > > > You mean program itself access the address(ie, 0xffffb7400000) is hang > > while access the address from the debugger is OK? > > Yes. > > > Can you reproduce it easily? > > 100% > > > Did you test it in real machine or qemu on x86? > > Both real and kvm. > > > Could you show me how I can reproduce it? > > Just run make check. > > > I want to test it in x86 machine, first of all. > > Unfortunately, I don't have any aarch64 platform now so maybe I have to > > run it on qemu on x86 until I can set up aarch64 platform if it is reproducible > > on real machine only. > > > >> > >> The kernel has been configured with transparent hugepages. > >> > >> CONFIG_TRANSPARENT_HUGEPAGE=y > >> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y > >> # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set > >> CONFIG_TRANSPARENT_HUGE_PAGECACHE=y > > > > What's the exact kernel version? > > Anything >= your commit. Thanks for the info. I cannot setup testing enviroment but when I read code, it seems we need pmd_wrprotect for non-hardware dirty architecture. Below helps? diff --git a/mm/huge_memory.c b/mm/huge_memory.c index e10a4fe..dc37c9a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1611,6 +1611,7 @@ int madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, tlb->fullmm); orig_pmd = pmd_mkold(orig_pmd); orig_pmd = pmd_mkclean(orig_pmd); + orig_pmd = pmd_wrprotect(orig_pmd); set_pmd_at(mm, addr, pmd, orig_pmd); tlb_remove_pmd_tlb_entry(tlb, pmd, addr); -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: minchan@kernel.org (Minchan Kim) Date: Fri, 16 Dec 2016 15:39:40 +0900 Subject: jemalloc testsuite stalls in memset In-Reply-To: References: <20161214235031.GA2912@bbox> Message-ID: <20161216063940.GA1334@bbox> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello, On Thu, Dec 15, 2016 at 10:24:47AM +0100, Andreas Schwab wrote: > On Dez 15 2016, Minchan Kim wrote: > > > You mean program itself access the address(ie, 0xffffb7400000) is hang > > while access the address from the debugger is OK? > > Yes. > > > Can you reproduce it easily? > > 100% > > > Did you test it in real machine or qemu on x86? > > Both real and kvm. > > > Could you show me how I can reproduce it? > > Just run make check. > > > I want to test it in x86 machine, first of all. > > Unfortunately, I don't have any aarch64 platform now so maybe I have to > > run it on qemu on x86 until I can set up aarch64 platform if it is reproducible > > on real machine only. > > > >> > >> The kernel has been configured with transparent hugepages. > >> > >> CONFIG_TRANSPARENT_HUGEPAGE=y > >> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y > >> # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set > >> CONFIG_TRANSPARENT_HUGE_PAGECACHE=y > > > > What's the exact kernel version? > > Anything >= your commit. Thanks for the info. I cannot setup testing enviroment but when I read code, it seems we need pmd_wrprotect for non-hardware dirty architecture. Below helps? diff --git a/mm/huge_memory.c b/mm/huge_memory.c index e10a4fe..dc37c9a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1611,6 +1611,7 @@ int madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, tlb->fullmm); orig_pmd = pmd_mkold(orig_pmd); orig_pmd = pmd_mkclean(orig_pmd); + orig_pmd = pmd_wrprotect(orig_pmd); set_pmd_at(mm, addr, pmd, orig_pmd); tlb_remove_pmd_tlb_entry(tlb, pmd, addr);