From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Rapoport Subject: Re: [PATCH v2 00/21] Refine memblock API Date: Thu, 26 Sep 2019 19:04:34 +0300 Message-ID: <20190926160433.GD32311@linux.ibm.com> References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:In-Reply-To:MIME-Version: References:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Gv+YX47Z3IZSyP/iedAiXpVEuSt0W6Ja4NrLyRil6Yg=; b=lm7NjnCvFHHhR7 M1yprKcQJiPnyhby/PlgX0tBAJ4caAIcf0+lpTWJ+ud4CsYNUN9SrlyiRyQvZcwBDSiqzXADrBuib 0pP9Y0ILhxRjlIU9KZyRWMQFgZ8Sn/uL64hyE+1QqZfMeY/qdBJ+RqxW7JmzPzfSeThlnWkSHXkaT GfkiphQO1H+SM0oaHXS361Fo/wu9NOql/vZVYOBDjsvUY65Avea14/d/LPEFBc9Rd3ZD00s2ppqBS GTNC5TzsSfI7wektUz/dPfy5oADw0hu3LgEMzQpS83rpHl6NLuPaDSVtTb/+QyEn/nTHPlACVtFvn k1xUe6167jvAWomUoPXg==; Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org To: Adam Ford Cc: Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Catalin Marinas , Heiko Carstens , linux-mips@vger.kernel.org, Max Filippov , devicetree , Guo Ren , sparclinux@vger.kernel.org, Fabio Estevam , Christoph Hellwig , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Richard Weinberger , x86@kernel.org, Russell King , kasan-dev , Geert Uytterhoeven , Mark Salter , Dennis Zhou , Matt Turner , linux-snps-arc@lists.infradead.org, Chris Healy , uclinux-h8-devel@lists.sourceforge.j Hi, On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam wrote: > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford wrote: > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > change. Do we need to setup a reserved-memory node like > > > imx6ul-ccimx6ulsom.dtsi did? > > > > I don't think so. > > > > Were you able to identify what was the exact commit that caused such regression? > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > internal allocation functions") that caused the regression with > Etnaviv. Can you please test with this change: diff --git a/mm/memblock.c b/mm/memblock.c index 7d4f61a..1f5a0eb 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, align = SMP_CACHE_BYTES; } - if (end > memblock.current_limit) - end = memblock.current_limit; - again: found = memblock_find_in_range_node(size, align, start, end, nid, flags); > I also noticed that if I create a reserved memory node as was done one > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > was getting errors regardless of the 'cma=256M' or not. > I don't have a problem using the reserved memory, but I guess I am not > sure what the amount should be. I know for the video decoding 1080p, > I have historically used cma=128M, but with the 3D also needing some > memory allocation, is that enough or should I use 256M? > > adam -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 From: rppt@linux.ibm.com (Mike Rapoport) Date: Thu, 26 Sep 2019 19:04:34 +0300 Subject: [PATCH v2 00/21] Refine memblock API In-Reply-To: References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> List-ID: Message-ID: <20190926160433.GD32311@linux.ibm.com> To: linux-snps-arc@lists.infradead.org Hi, On Thu, Sep 26, 2019@08:09:52AM -0500, Adam Ford wrote: > On Wed, Sep 25, 2019@10:17 AM Fabio Estevam wrote: > > > > On Wed, Sep 25, 2019@9:17 AM Adam Ford wrote: > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > change. Do we need to setup a reserved-memory node like > > > imx6ul-ccimx6ulsom.dtsi did? > > > > I don't think so. > > > > Were you able to identify what was the exact commit that caused such regression? > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > internal allocation functions") that caused the regression with > Etnaviv. Can you please test with this change: diff --git a/mm/memblock.c b/mm/memblock.c index 7d4f61a..1f5a0eb 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, align = SMP_CACHE_BYTES; } - if (end > memblock.current_limit) - end = memblock.current_limit; - again: found = memblock_find_in_range_node(size, align, start, end, nid, flags); > I also noticed that if I create a reserved memory node as was done one > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > was getting errors regardless of the 'cma=256M' or not. > I don't have a problem using the reserved memory, but I guess I am not > sure what the amount should be. I know for the video decoding 1080p, > I have historically used cma=128M, but with the 3D also needing some > memory allocation, is that enough or should I use 256M? > > adam -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 26 Sep 2019 19:04:34 +0300 From: Mike Rapoport Subject: Re: [PATCH v2 00/21] Refine memblock API References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-Id: <20190926160433.GD32311@linux.ibm.com> To: Adam Ford Cc: Fabio Estevam , Rich Felker , linux-ia64@vger.kernel.org, Petr Mladek , linux-sh@vger.kernel.org, Catalin Marinas , Heiko Carstens , Linux Kernel Mailing List , Max Filippov , Guo Ren , Michael Ellerman , sparclinux@vger.kernel.org, Christoph Hellwig , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Richard Weinberger , x86@kernel.org, Russell King , kasan-dev , Geert Uytterhoeven , Mark Salter , Dennis Zhou , Matt Turner , linux-snps-arc@lists.infradead.org, uclinux-h8-devel@lists.sourceforge.jp, devicetree , linux-xtensa@linux-xtensa.org, linux-um@lists.infradead.org, The etnaviv authors , linux-m68k@lists.linux-m68k.org, Rob Herring , Greentime Hu , xen-devel@lists.xenproject.org, Stafford Horne , Guan Xuetao , arm-soc , Michal Simek , Tony Luck , Linux Memory Management List , Greg Kroah-Hartman , USB list , linux-mips@vger.kernel.org, Paul Burton , Vineet Gupta , linux-alpha@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , openrisc@lists.librecores.org, Chris Healy List-ID: Hi, On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam wrote: > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford wrote: > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > change. Do we need to setup a reserved-memory node like > > > imx6ul-ccimx6ulsom.dtsi did? > > > > I don't think so. > > > > Were you able to identify what was the exact commit that caused such regression? > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > internal allocation functions") that caused the regression with > Etnaviv. Can you please test with this change: diff --git a/mm/memblock.c b/mm/memblock.c index 7d4f61a..1f5a0eb 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, align = SMP_CACHE_BYTES; } - if (end > memblock.current_limit) - end = memblock.current_limit; - again: found = memblock_find_in_range_node(size, align, start, end, nid, flags); > I also noticed that if I create a reserved memory node as was done one > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > was getting errors regardless of the 'cma=256M' or not. > I don't have a problem using the reserved memory, but I guess I am not > sure what the amount should be. I know for the video decoding 1080p, > I have historically used cma=128M, but with the 3D also needing some > memory allocation, is that enough or should I use 256M? > > adam -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Rapoport Date: Thu, 26 Sep 2019 19:04:34 +0300 Subject: [OpenRISC] [PATCH v2 00/21] Refine memblock API In-Reply-To: References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> Message-ID: <20190926160433.GD32311@linux.ibm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: openrisc@lists.librecores.org Hi, On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam wrote: > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford wrote: > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > change. Do we need to setup a reserved-memory node like > > > imx6ul-ccimx6ulsom.dtsi did? > > > > I don't think so. > > > > Were you able to identify what was the exact commit that caused such regression? > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > internal allocation functions") that caused the regression with > Etnaviv. Can you please test with this change: diff --git a/mm/memblock.c b/mm/memblock.c index 7d4f61a..1f5a0eb 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, align = SMP_CACHE_BYTES; } - if (end > memblock.current_limit) - end = memblock.current_limit; - again: found = memblock_find_in_range_node(size, align, start, end, nid, flags); > I also noticed that if I create a reserved memory node as was done one > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > was getting errors regardless of the 'cma=256M' or not. > I don't have a problem using the reserved memory, but I guess I am not > sure what the amount should be. I know for the video decoding 1080p, > I have historically used cma=128M, but with the 3D also needing some > memory allocation, is that enough or should I use 256M? > > adam -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2B61C4360C for ; Thu, 26 Sep 2019 16:07:22 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6F2C6208C3 for ; Thu, 26 Sep 2019 16:07:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F2C6208C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46fKZH4BH9zDqs1 for ; Fri, 27 Sep 2019 02:07:19 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=linux.ibm.com (client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com; envelope-from=rppt@linux.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46fKWq6xhPzDqkR for ; Fri, 27 Sep 2019 02:05:11 +1000 (AEST) Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x8QFvWKo096791 for ; Thu, 26 Sep 2019 12:04:58 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0b-001b2d01.pphosted.com with ESMTP id 2v90e389y2-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 26 Sep 2019 12:04:56 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Sep 2019 17:04:53 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp04.uk.ibm.com (192.168.101.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 26 Sep 2019 17:04:41 +0100 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x8QG4eJ744761120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Sep 2019 16:04:40 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C49C4A4054; Thu, 26 Sep 2019 16:04:40 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A5B1A405C; Thu, 26 Sep 2019 16:04:36 +0000 (GMT) Received: from linux.ibm.com (unknown [9.148.8.153]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 26 Sep 2019 16:04:36 +0000 (GMT) Date: Thu, 26 Sep 2019 19:04:34 +0300 From: Mike Rapoport To: Adam Ford Subject: Re: [PATCH v2 00/21] Refine memblock API References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 19092616-0016-0000-0000-000002B10922 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19092616-0017-0000-0000-00003311D734 Message-Id: <20190926160433.GD32311@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-26_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909260142 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Catalin Marinas , Heiko Carstens , linux-mips@vger.kernel.org, Max Filippov , devicetree , Guo Ren , sparclinux@vger.kernel.org, Fabio Estevam , Christoph Hellwig , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Richard Weinberger , x86@kernel.org, Russell King , kasan-dev , Geert Uytterhoeven , Mark Salter , Dennis Zhou , Matt Turner , linux-snps-arc@lists.infradead.org, Chris Healy , uclinux-h8-devel@lists.sourceforge.jp, Petr Mladek , linux-xtensa@linux-xtensa.org, linux-alpha@vger.kernel.org, linux-um@lists.infradead.org, The etnaviv authors , linux-m68k@lists.linux-m68k.org, Rob Herring , Greentime Hu , xen-devel@lists.xenproject.org, Stafford Horne , Guan Xuetao , arm-soc , Michal Simek , Tony Luck , Linux Memory Management List , Greg Kroah-Hartman , USB list , Linux Kernel Mailing List , Paul Burton , Vineet Gupta , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , openrisc@lists.librecores.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi, On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam wrote: > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford wrote: > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > change. Do we need to setup a reserved-memory node like > > > imx6ul-ccimx6ulsom.dtsi did? > > > > I don't think so. > > > > Were you able to identify what was the exact commit that caused such regression? > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > internal allocation functions") that caused the regression with > Etnaviv. Can you please test with this change: diff --git a/mm/memblock.c b/mm/memblock.c index 7d4f61a..1f5a0eb 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, align = SMP_CACHE_BYTES; } - if (end > memblock.current_limit) - end = memblock.current_limit; - again: found = memblock_find_in_range_node(size, align, start, end, nid, flags); > I also noticed that if I create a reserved memory node as was done one > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > was getting errors regardless of the 'cma=256M' or not. > I don't have a problem using the reserved memory, but I guess I am not > sure what the amount should be. I know for the video decoding 1080p, > I have historically used cma=128M, but with the 3D also needing some > memory allocation, is that enough or should I use 256M? > > adam -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9277C4360C for ; Thu, 26 Sep 2019 16:05:18 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AD7C121D6C for ; Thu, 26 Sep 2019 16:05:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD7C121D6C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iDWGL-0004VH-LA; Thu, 26 Sep 2019 16:05:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iDWGK-0004VC-2t for xen-devel@lists.xenproject.org; Thu, 26 Sep 2019 16:05:00 +0000 X-Inumbo-ID: 639ee048-e077-11e9-b588-bc764e2007e4 Received: from mx0a-001b2d01.pphosted.com (unknown [148.163.156.1]) by localhost (Halon) with ESMTPS id 639ee048-e077-11e9-b588-bc764e2007e4; Thu, 26 Sep 2019 16:04:59 +0000 (UTC) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x8QFuTbb023297 for ; Thu, 26 Sep 2019 12:04:58 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2v8ybp3rs2-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 26 Sep 2019 12:04:57 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Sep 2019 17:04:53 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp04.uk.ibm.com (192.168.101.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 26 Sep 2019 17:04:41 +0100 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x8QG4eJ744761120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Sep 2019 16:04:40 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C49C4A4054; Thu, 26 Sep 2019 16:04:40 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A5B1A405C; Thu, 26 Sep 2019 16:04:36 +0000 (GMT) Received: from linux.ibm.com (unknown [9.148.8.153]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 26 Sep 2019 16:04:36 +0000 (GMT) Date: Thu, 26 Sep 2019 19:04:34 +0300 From: Mike Rapoport To: Adam Ford References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 19092616-0016-0000-0000-000002B10922 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19092616-0017-0000-0000-00003311D734 Message-Id: <20190926160433.GD32311@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-26_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909260142 Subject: Re: [Xen-devel] [PATCH v2 00/21] Refine memblock API X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Catalin Marinas , Heiko Carstens , linux-mips@vger.kernel.org, Max Filippov , devicetree , Guo Ren , sparclinux@vger.kernel.org, Fabio Estevam , Christoph Hellwig , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Richard Weinberger , x86@kernel.org, Russell King , kasan-dev , Geert Uytterhoeven , Mark Salter , Dennis Zhou , Matt Turner , linux-snps-arc@lists.infradead.org, Chris Healy , uclinux-h8-devel@lists.sourceforge.jp, Petr Mladek , linux-xtensa@linux-xtensa.org, linux-alpha@vger.kernel.org, linux-um@lists.infradead.org, The etnaviv authors , linux-m68k@lists.linux-m68k.org, Rob Herring , Greentime Hu , xen-devel@lists.xenproject.org, Stafford Horne , Guan Xuetao , arm-soc , Michal Simek , Tony Luck , Linux Memory Management List , Greg Kroah-Hartman , USB list , Linux Kernel Mailing List , Paul Burton , Vineet Gupta , Michael Ellerman , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , openrisc@lists.librecores.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGksCgpPbiBUaHUsIFNlcCAyNiwgMjAxOSBhdCAwODowOTo1MkFNIC0wNTAwLCBBZGFtIEZvcmQg d3JvdGU6Cj4gT24gV2VkLCBTZXAgMjUsIDIwMTkgYXQgMTA6MTcgQU0gRmFiaW8gRXN0ZXZhbSA8 ZmVzdGV2YW1AZ21haWwuY29tPiB3cm90ZToKPiA+Cj4gPiBPbiBXZWQsIFNlcCAyNSwgMjAxOSBh dCA5OjE3IEFNIEFkYW0gRm9yZCA8YWZvcmQxNzNAZ21haWwuY29tPiB3cm90ZToKPiA+Cj4gPiA+ IEkgdHJpZWQgY21hPTI1Nk0gYW5kIG5vdGljZWQgdGhlIGNtYSBkdW1wIGF0IHRoZSBiZWdpbm5p bmcgZGlkbid0Cj4gPiA+IGNoYW5nZS4gIERvIHdlIG5lZWQgdG8gc2V0dXAgYSByZXNlcnZlZC1t ZW1vcnkgbm9kZSBsaWtlCj4gPiA+IGlteDZ1bC1jY2lteDZ1bHNvbS5kdHNpIGRpZD8KPiA+Cj4g PiBJIGRvbid0IHRoaW5rIHNvLgo+ID4KPiA+IFdlcmUgeW91IGFibGUgdG8gaWRlbnRpZnkgd2hh dCB3YXMgdGhlIGV4YWN0IGNvbW1pdCB0aGF0IGNhdXNlZCBzdWNoIHJlZ3Jlc3Npb24/Cj4gCj4g SSB3YXMgYWJsZSB0byBuYXJyb3cgaXQgZG93biB0aGUgOTJkMTJmOTU0NGI3ICgibWVtYmxvY2s6 IHJlZmFjdG9yCj4gaW50ZXJuYWwgYWxsb2NhdGlvbiBmdW5jdGlvbnMiKSB0aGF0IGNhdXNlZCB0 aGUgcmVncmVzc2lvbiB3aXRoCj4gRXRuYXZpdi4KCgpDYW4geW91IHBsZWFzZSB0ZXN0IHdpdGgg dGhpcyBjaGFuZ2U6CgpkaWZmIC0tZ2l0IGEvbW0vbWVtYmxvY2suYyBiL21tL21lbWJsb2NrLmMK aW5kZXggN2Q0ZjYxYS4uMWY1YTBlYiAxMDA2NDQKLS0tIGEvbW0vbWVtYmxvY2suYworKysgYi9t bS9tZW1ibG9jay5jCkBAIC0xMzU2LDkgKzEzNTYsNiBAQCBzdGF0aWMgcGh5c19hZGRyX3QgX19p bml0IG1lbWJsb2NrX2FsbG9jX3JhbmdlX25pZChwaHlzX2FkZHJfdCBzaXplLAogCQlhbGlnbiA9 IFNNUF9DQUNIRV9CWVRFUzsKIAl9CiAKLQlpZiAoZW5kID4gbWVtYmxvY2suY3VycmVudF9saW1p dCkKLQkJZW5kID0gbWVtYmxvY2suY3VycmVudF9saW1pdDsKLQogYWdhaW46CiAJZm91bmQgPSBt ZW1ibG9ja19maW5kX2luX3JhbmdlX25vZGUoc2l6ZSwgYWxpZ24sIHN0YXJ0LCBlbmQsIG5pZCwK IAkJCQkJICAgIGZsYWdzKTsKIAo+IEkgYWxzbyBub3RpY2VkIHRoYXQgaWYgSSBjcmVhdGUgYSBy ZXNlcnZlZCBtZW1vcnkgbm9kZSBhcyB3YXMgZG9uZSBvbmUKPiBpbXg2dWwtY2NpbXg2dWxzb20u ZHRzaSB0aGUgM0Qgc2VlbXMgdG8gd29yayBhZ2FpbiwgYnV0IHdpdGhvdXQgaXQsIEkKPiB3YXMg Z2V0dGluZyBlcnJvcnMgcmVnYXJkbGVzcyBvZiB0aGUgJ2NtYT0yNTZNJyBvciBub3QuCj4gSSBk b24ndCBoYXZlIGEgcHJvYmxlbSB1c2luZyB0aGUgcmVzZXJ2ZWQgbWVtb3J5LCBidXQgSSBndWVz cyBJIGFtIG5vdAo+IHN1cmUgd2hhdCB0aGUgYW1vdW50IHNob3VsZCBiZS4gIEkga25vdyBmb3Ig dGhlIHZpZGVvIGRlY29kaW5nIDEwODBwLAo+IEkgaGF2ZSBoaXN0b3JpY2FsbHkgdXNlZCBjbWE9 MTI4TSwgYnV0IHdpdGggdGhlIDNEIGFsc28gbmVlZGluZyBzb21lCj4gbWVtb3J5IGFsbG9jYXRp b24sIGlzIHRoYXQgZW5vdWdoIG9yIHNob3VsZCBJIHVzZSAyNTZNPwo+IAo+IGFkYW0KCi0tIApT aW5jZXJlbHkgeW91cnMsCk1pa2UuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZv L3hlbi1kZXZlbA==