From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03499C65BA7 for ; Fri, 5 Oct 2018 15:17:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CA3E62084D for ; Fri, 5 Oct 2018 15:17:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA3E62084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728693AbeJEWQq convert rfc822-to-8bit (ORCPT ); Fri, 5 Oct 2018 18:16:46 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:53556 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728329AbeJEWQp (ORCPT ); Fri, 5 Oct 2018 18:16:45 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8F3A380D; Fri, 5 Oct 2018 08:17:36 -0700 (PDT) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 403F63F5D3; Fri, 5 Oct 2018 08:17:33 -0700 (PDT) Date: Fri, 05 Oct 2018 16:17:30 +0100 Message-ID: <86y3bctoc5.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Matthias Brugger Cc: Matthias Brugger , matthias.bgg@kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, tglx@linutronix.de, jason@lakedaemon.net, robert.richter@cavium.com, suzuki.poulose@arm.com, shankerd@codeaurora.org, xiexiuqi@huawei.com, Dave.Martin@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] irqchip/gic-v3-its: Add early memory allocation errata In-Reply-To: <93532c6a-0a84-4063-3f9f-171490985cbb@gmail.com> References: <20180912095232.2110-1-matthias.bgg@kernel.org> <95733d12-ee1d-9874-16a7-c614cc0ce8cd@arm.com> <8ef6b381-e170-30de-ad0e-fae8ccf189e5@suse.com> <1d227152-2770-3e93-f78c-71e7a3b4fe76@arm.com> <93532c6a-0a84-4063-3f9f-171490985cbb@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 05 Oct 2018 15:13:48 +0100, Matthias Brugger wrote: > > > > On 05/10/2018 15:42, Marc Zyngier wrote: > > On 05/10/18 13:33, Matthias Brugger wrote: > >> > >> > >> On 05/10/2018 12:55, Marc Zyngier wrote: > >>> Hi Matthias, > >>> > >>> On 04/10/18 23:11, Matthias Brugger wrote: > >>>> Friendly reminder, if anyone has any comment on the patch :) > >>>> > >>>> On 9/12/18 11:52 AM, matthias.bgg@kernel.org wrote: > >>>>> From: Matthias Brugger > >>>>> > >>>>> Some hardware does not implement two-level page tables so that > >>>>> the amount of contigious memory needed by the baser is bigger > >>>>> then the zone order. This is a known problem on Cavium Thunderx > >>>>> with 4K page size. > >>>>> > >>>>> We fix this by adding an errata which allocates the memory early > >>>>> in the boot cycle, using the memblock allocator. > >>>>> > >>>>> Signed-off-by: Matthias Brugger > >>>>> --- > >>>>>    arch/arm64/Kconfig               | 12 ++++++++ > >>>>>    arch/arm64/include/asm/cpucaps.h |  3 +- > >>>>>    arch/arm64/kernel/cpu_errata.c   | 33 +++++++++++++++++++++ > >>>>>    drivers/irqchip/irq-gic-v3-its.c | 50 ++++++++++++++++++++------------ > >>>>>    4 files changed, 79 insertions(+), 19 deletions(-) > >>> > >>> My only comment would be to state how much I dislike both the HW and the > >>> patch... ;-) The idea that we have some erratum that depends on the page size > >>> doesn't feel good at all. > >>> > >> > >> Well ugly HW needs ugly patches ;-) > >> > >>>>> > >>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > >>>>> index 1b1a0e95c751..dfd9fe08f0b2 100644 > >>>>> --- a/arch/arm64/Kconfig > >>>>> +++ b/arch/arm64/Kconfig > >>>>> @@ -597,6 +597,18 @@ config QCOM_FALKOR_ERRATUM_E1041 > >>>>>            If unsure, say Y. > >>>>>    +config CAVIUM_ALLOC_ITS_TABLE_EARLY > >>>>> +    bool "Cavium Thunderx: Allocate the its table early" > >>>>> +    default y > >>>>> +    depends on ARM64_4K_PAGES && FORCE_MAX_ZONEORDER < 13 > >>> > >>> Here's a though: Why don't we ensure that FORCE_MAX_ZONEORDER is such as we > >>> could always allocate the same amount of memory, no matter what the page size > >>> is? That, or bump FORCE_MAX_ZONEORDER to 13 if the kernel includes support > >>> for TX1. > >>> > >> > >> Bumping FORCE_MAX_ZONEORDER when TX1 is supported was proposed here: > >> https://patchwork.kernel.org/patch/6322281/ > >> > >> To bring in some more history, the CMA approach ended with this discussion: > >> https://patchwork.kernel.org/patch/9888041/ > >> > >>> Any of this of course requires buy-in from the arm64 maintainers, as this is > >>> quite a departure from the way things work so far. > >>> > >> > >> With my distribution head on, I would prefer a solution that does not change > >> FORCE_MAX_ZONEORDER. That's how I came to the idea providing a third solution to > >> the same problem :) > > > > Why is that a problem? What impact does this have on your favourite distro? > > > > The impact is on changing FORCE_MAX_ZONEORDER on an already released > kernel will break Kernel ABI and with that all external modules. I > know that's nothing upstream cares too much about, but the distros > do :) Unfortunately, that's something you're bringing upon yourself, and I'm afraid I can't really take this into account. You could always bump that ABI if you really want to support this platform as, at the end of the day, this is something you're in control of. But I'd really like to hear what Catalin or Will think of this (Will wasn't massively impressed by this 3 years ago, and I wonder if his approach has changed since). Thanks, M. -- Jazz is not dead, it just smell funny.