From: Catalin Marinas <catalin.marinas@arm.com> To: Andrew Pinski <apinski@caviumnetworks.com> Cc: Timur Tabi <timur@codeaurora.org>, Ganesh Mahendran <opensource.ganesh@gmail.com>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, stable@vger.kernel.org, rrichter@cavium.com, tchalamarla@cavium.com, Shanker Donthineni <shankerd@codeaurora.org>, apinski@cavium.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] Revert "arm64: Increase the max granular size" Date: Thu, 17 Mar 2016 18:37:16 +0000 [thread overview] Message-ID: <20160317183715.GE11623@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <56EAF244.2090805@caviumnetworks.com> On Thu, Mar 17, 2016 at 11:07:00AM -0700, Andrew Pinski wrote: > On 3/17/2016 7:27 AM, Catalin Marinas wrote: > >On Wed, Mar 16, 2016 at 10:26:08AM -0500, Timur Tabi wrote: > >>Catalin Marinas wrote: > >>>Why do you need your own defconfig? If it's just on the short term until > >>>all your code is upstream, that's fine, but this goes against the single > >>>Image aim. I would like defconfig to cover all supported SoCs (and yes, > >>>ACPI on by default once we deem it !EXPERT anymore), though at some > >>>point we may need a server/mobile split (if the generated image is too > >>>large, maybe more stuff being built as modules). > >>Yes, that's exactly it. Ours is an ACPI system, and so we have to have our > >>own defconfig for now. We're holding off on pushing our own defconfig > >>changes (enabling drivers, etc) until ACPI is enabled in > >>arch/arm64/configs/defconfig. > >Is there anything that prevents you from providing a dtb/dts for this > >SoC? > > Note ThunderX's SOC have customers where some are embedded users (uboot) > and server users (UEFI). The cores always have 128 byte cacheline size. So > please don't make this dependent on ACPI. Definitely not, this has nothing to do with ACPI or servers. My comment on different defconfig was more about things like 64K pages vs 4K, if the former ever prove useful in practice. Who knows, we may even see ACPI for IoT ;) (with MS involvement in Raspberry Pi) > Note the defconfig works correctly on T88. We have two aspects to address: one is correctness and the other is performance. But we bundle everything under L1_CACHE_BYTES which affects platforms that don't have such large cache lines (actually, it may even affect those that do; has anyone done actual benchmarks?) As Will suggested, we could try to revert L1_CACHE_BYTES back to 64 and make ARCH_DMA_MINALIGN run-time based on CWG for correctness. Would this work on the Cavium hardware? -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] Revert "arm64: Increase the max granular size" Date: Thu, 17 Mar 2016 18:37:16 +0000 [thread overview] Message-ID: <20160317183715.GE11623@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <56EAF244.2090805@caviumnetworks.com> On Thu, Mar 17, 2016 at 11:07:00AM -0700, Andrew Pinski wrote: > On 3/17/2016 7:27 AM, Catalin Marinas wrote: > >On Wed, Mar 16, 2016 at 10:26:08AM -0500, Timur Tabi wrote: > >>Catalin Marinas wrote: > >>>Why do you need your own defconfig? If it's just on the short term until > >>>all your code is upstream, that's fine, but this goes against the single > >>>Image aim. I would like defconfig to cover all supported SoCs (and yes, > >>>ACPI on by default once we deem it !EXPERT anymore), though at some > >>>point we may need a server/mobile split (if the generated image is too > >>>large, maybe more stuff being built as modules). > >>Yes, that's exactly it. Ours is an ACPI system, and so we have to have our > >>own defconfig for now. We're holding off on pushing our own defconfig > >>changes (enabling drivers, etc) until ACPI is enabled in > >>arch/arm64/configs/defconfig. > >Is there anything that prevents you from providing a dtb/dts for this > >SoC? > > Note ThunderX's SOC have customers where some are embedded users (uboot) > and server users (UEFI). The cores always have 128 byte cacheline size. So > please don't make this dependent on ACPI. Definitely not, this has nothing to do with ACPI or servers. My comment on different defconfig was more about things like 64K pages vs 4K, if the former ever prove useful in practice. Who knows, we may even see ACPI for IoT ;) (with MS involvement in Raspberry Pi) > Note the defconfig works correctly on T88. We have two aspects to address: one is correctness and the other is performance. But we bundle everything under L1_CACHE_BYTES which affects platforms that don't have such large cache lines (actually, it may even affect those that do; has anyone done actual benchmarks?) As Will suggested, we could try to revert L1_CACHE_BYTES back to 64 and make ARCH_DMA_MINALIGN run-time based on CWG for correctness. Would this work on the Cavium hardware? -- Catalin
next prev parent reply other threads:[~2016-03-17 18:37 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-03-16 9:32 [PATCH] Revert "arm64: Increase the max granular size" Ganesh Mahendran 2016-03-16 9:32 ` Ganesh Mahendran 2016-03-16 10:07 ` Will Deacon 2016-03-16 10:07 ` Will Deacon 2016-03-16 13:06 ` Timur Tabi 2016-03-16 13:06 ` Timur Tabi 2016-03-16 14:03 ` Mark Rutland 2016-03-16 14:03 ` Mark Rutland 2016-03-16 14:35 ` Will Deacon 2016-03-16 14:35 ` Will Deacon 2016-03-16 14:54 ` Mark Rutland 2016-03-16 14:54 ` Mark Rutland 2016-03-16 14:18 ` Catalin Marinas 2016-03-16 14:18 ` Catalin Marinas 2016-03-16 15:26 ` Timur Tabi 2016-03-16 15:26 ` Timur Tabi 2016-03-17 14:27 ` Catalin Marinas 2016-03-17 14:27 ` Catalin Marinas 2016-03-17 14:49 ` Timur Tabi 2016-03-17 14:49 ` Timur Tabi 2016-03-17 15:37 ` Catalin Marinas 2016-03-17 15:37 ` Catalin Marinas 2016-03-17 16:03 ` Marc Zyngier 2016-03-17 16:03 ` Marc Zyngier 2016-03-17 18:07 ` Andrew Pinski 2016-03-17 18:07 ` Andrew Pinski 2016-03-17 18:34 ` Timur Tabi 2016-03-17 18:34 ` Timur Tabi 2016-03-17 18:37 ` Catalin Marinas [this message] 2016-03-17 18:37 ` Catalin Marinas 2016-03-18 21:05 ` Chalamarla, Tirumalesh 2016-03-18 21:05 ` Chalamarla, Tirumalesh 2016-03-18 21:05 ` Chalamarla, Tirumalesh 2016-03-21 1:56 ` Ganesh Mahendran 2016-03-21 1:56 ` Ganesh Mahendran 2016-03-21 1:56 ` Ganesh Mahendran 2016-03-21 17:14 ` Catalin Marinas 2016-03-21 17:14 ` Catalin Marinas 2016-03-21 17:14 ` Catalin Marinas 2016-03-21 17:23 ` Will Deacon 2016-03-21 17:23 ` Will Deacon 2016-03-21 17:23 ` Will Deacon 2016-03-21 17:33 ` Catalin Marinas 2016-03-21 17:33 ` Catalin Marinas 2016-03-21 17:33 ` Catalin Marinas 2016-03-21 17:39 ` Chalamarla, Tirumalesh 2016-03-21 17:39 ` Chalamarla, Tirumalesh 2016-03-21 17:39 ` Chalamarla, Tirumalesh [not found] ` <CAPub14-sFgx=oCHzJPb9h9b_V0rbn5UAMDNJ-yTkjhz38JPqMQ@mail.gmail.com> [not found] ` <10fef112-37f1-0a1b-b5af-435acd032f01@codeaurora.org> 2017-04-06 7:22 ` Imran Khan 2017-04-06 7:22 ` Imran Khan 2017-04-06 7:22 ` Imran Khan 2017-04-06 15:58 ` Catalin Marinas 2017-04-06 15:58 ` Catalin Marinas 2017-04-07 2:06 ` Ganesh Mahendran 2017-04-07 2:06 ` Ganesh Mahendran 2017-04-07 8:59 ` Catalin Marinas 2017-04-07 8:59 ` Catalin Marinas 2017-04-12 5:13 ` Imran Khan 2017-04-12 5:13 ` Imran Khan 2017-04-12 14:00 ` Chalamarla, Tirumalesh 2017-04-12 14:00 ` Chalamarla, Tirumalesh 2017-04-12 14:00 ` Chalamarla, Tirumalesh 2017-04-17 7:35 ` Imran Khan 2017-04-17 7:35 ` Imran Khan 2017-04-17 7:35 ` Imran Khan 2017-04-17 10:38 ` Sunil Kovvuri 2017-04-17 10:38 ` Sunil Kovvuri 2017-04-17 10:38 ` Sunil Kovvuri 2017-04-18 14:48 ` Catalin Marinas 2017-04-18 14:48 ` Catalin Marinas 2017-04-18 14:48 ` Catalin Marinas 2017-04-18 17:05 ` Sunil Kovvuri 2017-04-18 17:05 ` Sunil Kovvuri 2017-04-18 17:05 ` Sunil Kovvuri 2017-04-19 12:01 ` Catalin Marinas 2017-04-19 12:01 ` Catalin Marinas 2017-04-19 12:01 ` Catalin Marinas 2017-04-19 13:11 ` Sunil Kovvuri 2017-04-19 13:11 ` Sunil Kovvuri 2017-04-19 13:11 ` Sunil Kovvuri 2017-04-25 6:42 ` Ding Tianhong 2017-04-25 6:42 ` Ding Tianhong 2017-04-25 6:42 ` Ding Tianhong 2017-04-18 18:21 ` Chalamarla, Tirumalesh 2017-04-18 18:21 ` Chalamarla, Tirumalesh 2017-04-18 18:21 ` Chalamarla, Tirumalesh 2017-04-11 4:40 ` Jon Masters 2017-04-11 4:40 ` Jon Masters 2017-04-11 4:40 ` Jon Masters -- strict thread matches above, loose matches on Subject: below -- 2016-03-16 9:37 Ganesh Mahendran 2016-03-16 9:27 Ganesh Mahendran
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160317183715.GE11623@e104818-lin.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=apinski@cavium.com \ --cc=apinski@caviumnetworks.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=opensource.ganesh@gmail.com \ --cc=rrichter@cavium.com \ --cc=shankerd@codeaurora.org \ --cc=stable@vger.kernel.org \ --cc=tchalamarla@cavium.com \ --cc=timur@codeaurora.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.