Messages in this thread | | | Date | Tue, 12 May 2015 19:46:51 +0200 | From | Robert Richter <> | Subject | Re: [PATCH 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX |
| |
On 12.05.15 18:24:16, Will Deacon wrote: > On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter 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? > > > * set FORCE_MAX_ZONEORDER to 13 as default, > > > > * set FORCE_MAX_ZONEORDER to 13 if ARM_GIC_V3 is set, > > > > * set FORCE_MAX_ZONEORDER to 13 if ARCH_THUNDER is set (this patch), > > I'm not hugely fond of these suggestions, as there's still no guarantee > that such a huge allocation is going to succeed and we end up bumping > MAX_ORDER for all platforms in defconfig if we enable THUNDER there.
I actually was expecting this...
> > * use hugepages if enabled (defconfig has the following options > > enable: CGROUP_HUGETLB, TRANSPARENT_HUGEPAGE, HUGETLBFS, this might > > work with current default kernel without changing defconfig > > options), > > I don't think hugepages help with DMA. > > > * use devicetree to reserve mem for gicv3 (need to check ACPI).
I am quite a bit concerned letting firmware handle this. But if that would solve it, fine.
> Using a carveout like this might be the best bet. I assume the memory used > by the ITS can never be reclaimed by the syste (and therefore there's no > issue with wastage)? > > > Do you see any direction? > > Dunno, does CMA also require the MAX_ORDER bump?
Looks promising at the first glance. Will look into it.
Thanks,
-Robert
| |