Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932118AbbEUIf4 (ORCPT ); Thu, 21 May 2015 04:35:56 -0400 Received: from foss.arm.com ([217.140.101.70]:40661 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754519AbbEUIfv (ORCPT ); Thu, 21 May 2015 04:35:51 -0400 Message-ID: <555D98E3.2030908@arm.com> Date: Thu, 21 May 2015 09:35:47 +0100 From: Marc Zyngier Organization: ARM Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Catalin Marinas , Robert Richter CC: Robert Richter , Will Deacon , "linux-kernel@vger.kernel.org" , Tirumalesh Chalamarla , Radha Mohan Chintakuntla , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX 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> <20150520123159.GE10428@rric.localhost> <20150520164858.GD29424@e104818-lin.cambridge.arm.com> In-Reply-To: <20150520164858.GD29424@e104818-lin.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1911 Lines: 45 On 20/05/15 17:48, Catalin Marinas wrote: > On Wed, May 20, 2015 at 02:31:59PM +0200, Robert Richter wrote: >> 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. > > Can we not reserve a chunk of memory and pass the information to the > kernel via DT (/memreserve/ and a new GIC-specific binding)? That would have to be done on a per-table basis then. And how would that work with ACPI? I don't think the ACPI ITS table specifies anything in that respect. We're just facing the horrible reality that linear tables are not very well suited to sparse addressing. Nobody copied the VAX MMU model for a reason... until now. M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/