From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753426AbbETMc2 (ORCPT ); Wed, 20 May 2015 08:32:28 -0400 Received: from mail-bl2on0084.outbound.protection.outlook.com ([65.55.169.84]:7520 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752313AbbETMc0 (ORCPT ); Wed, 20 May 2015 08:32:26 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Robert.Richter@caviumnetworks.com; Date: Wed, 20 May 2015 14:31:59 +0200 From: Robert Richter To: Marc Zyngier CC: Will Deacon , Robert Richter , Catalin Marinas , Tirumalesh Chalamarla , Radha Mohan Chintakuntla , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX Message-ID: <20150520123159.GE10428@rric.localhost> References: <1430686172-18222-1-git-send-email-rric@kernel.org> <1430686172-18222-5-git-send-email-rric@kernel.org> <20150505105329.GC1550@arm.com> <20150511091438.GW4251@rric.localhost> <20150512123056.GA2062@arm.com> <20150512162049.GP10428@rric.localhost> <20150512172416.GF2062@arm.com> <20150520132213.1128eb90@why.wild-wind.fr.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150520132213.1128eb90@why.wild-wind.fr.eu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [78.53.86.157] X-ClientProxiedBy: HE1PR01CA0033.eurprd01.prod.exchangelabs.com (25.163.2.171) To CO2PR0701MB808.namprd07.prod.outlook.com (10.141.246.26) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0701MB808; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:CO2PR0701MB808;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0701MB808; X-Forefront-PRVS: 0582641F53 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6069001)(6009001)(164054003)(24454002)(189002)(51704005)(199003)(5001830100001)(5001860100001)(23726002)(122386002)(110136002)(86362001)(46406003)(5001960100002)(4001350100001)(106356001)(87976001)(33656002)(76506005)(189998001)(42186005)(40100003)(105586002)(77096005)(19580395003)(68736005)(92566002)(83506001)(97756001)(2950100001)(46102003)(64706001)(47776003)(66066001)(19580405001)(101416001)(76176999)(50466002)(4001540100001)(77156002)(93886004)(50986999)(62966003)(97736004)(54356999)(81156007);DIR:OUT;SFP:1101;SCL:1;SRVR:CO2PR0701MB808;H:rric.localhost;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2015 12:32:15.5195 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0701MB808 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20.05.15 13:22:13, Marc Zyngier wrote: > On Tue, 12 May 2015 18:24:16 +0100 > Will Deacon wrote: > > On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote: > > > On 12.05.15 13:30:57, Will Deacon wrote: > > > For allocation of 16MB cont. phys mem of a defconfig kernel (4KB > > > default pagesize) I see this different approaches: > > > > 16MB sounds like an awful lot. Is this because you have tonnes of MSIs or > > a sparse DeviceID space or both? > > That's probably due to the sparseness of the DeviceID space. With some > form of bridge number encoded on top of the BFD number, the device > table is enormous, and I don't see a nice way to avoid it... Right. At the momement out of 21 bits (16MB) we currently have 2 spare bits, which reduces the actually size used to 4MB. Though, for the current cpu model we can reduce it at least to 8MB total. I will come up with an additional patch setting this to 8MB. As said before, I also write on a patch to use CMA. Thanks, -Robert