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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/