From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 3vD9cf1272zDq5W for ; Thu, 2 Feb 2017 04:49:37 +1100 (AEDT) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v11HnQfU098125 for ; Wed, 1 Feb 2017 12:49:36 -0500 Received: from e24smtp04.br.ibm.com (e24smtp04.br.ibm.com [32.104.18.25]) by mx0a-001b2d01.pphosted.com with ESMTP id 28bjec600n-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 01 Feb 2017 12:49:35 -0500 Received: from localhost by e24smtp04.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 Feb 2017 15:49:31 -0200 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by d24dlp01.br.ibm.com (Postfix) with ESMTP id ADD2E3520070 for ; Wed, 1 Feb 2017 12:48:55 -0500 (EST) Received: from d24av05.br.ibm.com (d24av05.br.ibm.com [9.18.232.44]) by d24relay01.br.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v11HnSFY4427876 for ; Wed, 1 Feb 2017 15:49:28 -0200 Received: from d24av05.br.ibm.com (localhost [127.0.0.1]) by d24av05.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v11HnS08029921 for ; Wed, 1 Feb 2017 15:49:28 -0200 From: Thiago Jung Bauermann To: linuxppc-dev@lists.ozlabs.org Cc: Michael Ellerman , Sukadev Bhattiprolu , Paul Clarke , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size Date: Wed, 01 Feb 2017 15:49:23 -0200 In-Reply-To: <87wpdatqrt.fsf@concordia.ellerman.id.au> References: <20160805061041.GA31857@us.ibm.com> <20160809171131.GA2329@us.ibm.com> <87wpdatqrt.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Message-Id: <2499748.LKgOIUjhgo@morokweng> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hello, Am Mittwoch, 1. Februar 2017, 16:37:58 BRST schrieb Michael Ellerman: > Sukadev Bhattiprolu writes: > > Paul Clarke [pc@us.ibm.com] wrote: > > --- > >=20 > > From f9e9e8460206bc3fa7eaa741b9a2bde22870b9e0 Mon Sep 17 00:00:00 2001 >=20 > I know it's been a while but I think it would still be good to get this > in a shape that we can merge it. Sorry if this has been tried and didn't work or if I'm missing something=20 obvious: Instead of this method of trying a small RMA size and rebooting to try a=20 bigger size, could the "min RMA percentage of total RAM" field of the=20 ibm_architecture_vec be used? LoPAPR says that "The Initial size of the RMA is set to the greater of the= =20 values indicated by bytes 24-27 [min RMA] or 32 [min RMA percentage of tota= l=20 RAM] of option vector number 2 =E2=80=9COpen Firmware=E2=80=9D or minimum R= MA size supported=20 by the platform and capped by the maximum memory defined for the partition = and=20 the maximum size of the RMA supported by the platform. The respective selec= ted=20 values are reported in the length of the first memory property." My understanding is that these patches are intended for big guests with man= y=20 processors, but the RMA size isn't changed to 512MB outright because of=20 worries that it could affect smaller guests. Since guests with many process= ors=20 tend to have more RAM as well, specifying a min RMA size of 256MB and a min= =20 RMA percentage of, say, 10% or 20% could make the host automatically alloca= te=20 an adequate RMA size in the first boot. =2D-=20 Thiago Jung Bauermann IBM Linux Technology Center From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753997AbdBARtg convert rfc822-to-8bit (ORCPT ); Wed, 1 Feb 2017 12:49:36 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:42330 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753003AbdBARte (ORCPT ); Wed, 1 Feb 2017 12:49:34 -0500 From: Thiago Jung Bauermann To: linuxppc-dev@lists.ozlabs.org Cc: Michael Ellerman , Sukadev Bhattiprolu , Paul Clarke , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size Date: Wed, 01 Feb 2017 15:49:23 -0200 User-Agent: KMail/5.2.3 (Linux/4.4.0-59-generic; KDE/5.28.0; x86_64; ; ) In-Reply-To: <87wpdatqrt.fsf@concordia.ellerman.id.au> References: <20160805061041.GA31857@us.ibm.com> <20160809171131.GA2329@us.ibm.com> <87wpdatqrt.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17020117-0020-0000-0000-00000283278F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17020117-0021-0000-0000-0000309D4507 Message-Id: <2499748.LKgOIUjhgo@morokweng> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-01_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702010176 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Am Mittwoch, 1. Februar 2017, 16:37:58 BRST schrieb Michael Ellerman: > Sukadev Bhattiprolu writes: > > Paul Clarke [pc@us.ibm.com] wrote: > > --- > > > > From f9e9e8460206bc3fa7eaa741b9a2bde22870b9e0 Mon Sep 17 00:00:00 2001 > > I know it's been a while but I think it would still be good to get this > in a shape that we can merge it. Sorry if this has been tried and didn't work or if I'm missing something obvious: Instead of this method of trying a small RMA size and rebooting to try a bigger size, could the "min RMA percentage of total RAM" field of the ibm_architecture_vec be used? LoPAPR says that "The Initial size of the RMA is set to the greater of the values indicated by bytes 24-27 [min RMA] or 32 [min RMA percentage of total RAM] of option vector number 2 “Open Firmware” or minimum RMA size supported by the platform and capped by the maximum memory defined for the partition and the maximum size of the RMA supported by the platform. The respective selected values are reported in the length of the first memory property." My understanding is that these patches are intended for big guests with many processors, but the RMA size isn't changed to 512MB outright because of worries that it could affect smaller guests. Since guests with many processors tend to have more RAM as well, specifying a min RMA size of 256MB and a min RMA percentage of, say, 10% or 20% could make the host automatically allocate an adequate RMA size in the first boot. -- Thiago Jung Bauermann IBM Linux Technology Center