Re: [PATCH] Revert "arm64: Increase the max granular size"

On 2017/4/19 21:11, Sunil Kovvuri wrote: > On Wed, Apr 19, 2017 at 5:31 PM, Catalin Marinas > wrote: >> On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote: >>> On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas >>> wrote: On Mon,

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 2017/4/19 21:11, Sunil Kovvuri wrote: > On Wed, Apr 19, 2017 at 5:31 PM, Catalin Marinas > wrote: >> On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote: >>> On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas >>> wrote: On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Apr 19, 2017 at 5:31 PM, Catalin Marinas wrote: > On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote: >> On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas >> wrote: >> > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Apr 19, 2017 at 5:31 PM, Catalin Marinas wrote: > On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote: >> On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas >> wrote: >> > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote: >> >> >> >> Do you have an explanation on

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote: > On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas > wrote: > > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote: > >> >> >> Do you have an explanation on the performance variation when > >>

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Tue, Apr 18, 2017 at 10:35:02PM +0530, Sunil Kovvuri wrote: > On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas > wrote: > > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote: > >> >> >> Do you have an explanation on the performance variation when > >> >> >> L1_CACHE_BYTES

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/17/17, 12:35 AM, "Imran Khan" wrote: On 4/12/2017 7:30 PM, Chalamarla, Tirumalesh wrote: > > > On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan"

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/17/17, 12:35 AM, "Imran Khan" wrote: On 4/12/2017 7:30 PM, Chalamarla, Tirumalesh wrote: > > > On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan" wrote: > > On 4/7/2017 7:36 AM, Ganesh Mahendran wrote: > > 2017-04-06 23:58 GMT+08:00

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas wrote: > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote: >> >> >> Do you have an explanation on the performance variation when >> >> >> L1_CACHE_BYTES is changed? We'd need to understand how the

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Tue, Apr 18, 2017 at 8:18 PM, Catalin Marinas wrote: > On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote: >> >> >> Do you have an explanation on the performance variation when >> >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network >> >> stack >> >>

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote: > >> >> Do you have an explanation on the performance variation when > >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network > >> stack > >> >> is affected by L1_CACHE_BYTES, in which context it uses it

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote: > >> >> Do you have an explanation on the performance variation when > >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network > >> stack > >> >> is affected by L1_CACHE_BYTES, in which context it uses it

Re: [PATCH] Revert "arm64: Increase the max granular size"

>> >> Do you have an explanation on the performance variation when >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network >> stack >> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for >> >> non-coherent DMA?). >> > >> > network

Re: [PATCH] Revert "arm64: Increase the max granular size"

>> >> Do you have an explanation on the performance variation when >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network >> stack >> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for >> >> non-coherent DMA?). >> > >> > network

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/12/2017 7:30 PM, Chalamarla, Tirumalesh wrote: > > > On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan" > kim...@codeaurora.org> wrote: > > On 4/7/2017 7:36 AM, Ganesh Mahendran wrote: > > 2017-04-06 23:58

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/12/2017 7:30 PM, Chalamarla, Tirumalesh wrote: > > > On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan" > kim...@codeaurora.org> wrote: > > On 4/7/2017 7:36 AM, Ganesh Mahendran wrote: > > 2017-04-06 23:58 GMT+08:00 Catalin Marinas : > >> On Thu, Apr 06, 2017 at

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan" wrote: On 4/7/2017 7:36 AM, Ganesh Mahendran wrote: > 2017-04-06 23:58 GMT+08:00 Catalin Marinas : >> On Thu,

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan" wrote: On 4/7/2017 7:36 AM, Ganesh Mahendran wrote: > 2017-04-06 23:58 GMT+08:00 Catalin Marinas : >> On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: >>> On 4/5/2017 10:13 AM, Imran Khan wrote:

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/7/2017 7:36 AM, Ganesh Mahendran wrote: > 2017-04-06 23:58 GMT+08:00 Catalin Marinas : >> On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: >>> On 4/5/2017 10:13 AM, Imran Khan wrote: > We may have to revisit this logic and consider L1_CACHE_BYTES the

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/7/2017 7:36 AM, Ganesh Mahendran wrote: > 2017-04-06 23:58 GMT+08:00 Catalin Marinas : >> On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: >>> On 4/5/2017 10:13 AM, Imran Khan wrote: > We may have to revisit this logic and consider L1_CACHE_BYTES the > _minimum_ of cache

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 04/06/2017 11:58 AM, Catalin Marinas wrote: > The Cavium guys haven't shown any numbers (IIUC) to back the > L1_CACHE_BYTES performance improvement but I would not revert the > original commit since ARCH_DMA_MINALIGN definitely needs to cover the > maximum available cache line size, which is

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 04/06/2017 11:58 AM, Catalin Marinas wrote: > The Cavium guys haven't shown any numbers (IIUC) to back the > L1_CACHE_BYTES performance improvement but I would not revert the > original commit since ARCH_DMA_MINALIGN definitely needs to cover the > maximum available cache line size, which is

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Fri, Apr 07, 2017 at 10:06:31AM +0800, Ganesh Mahendran wrote: > 2017-04-06 23:58 GMT+08:00 Catalin Marinas : > > On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: > >> On 4/5/2017 10:13 AM, Imran Khan wrote: > >> >> We may have to revisit this logic and

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Fri, Apr 07, 2017 at 10:06:31AM +0800, Ganesh Mahendran wrote: > 2017-04-06 23:58 GMT+08:00 Catalin Marinas : > > On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: > >> On 4/5/2017 10:13 AM, Imran Khan wrote: > >> >> We may have to revisit this logic and consider L1_CACHE_BYTES the >

Re: [PATCH] Revert "arm64: Increase the max granular size"

2017-04-06 23:58 GMT+08:00 Catalin Marinas : > On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: >> On 4/5/2017 10:13 AM, Imran Khan wrote: >> >> We may have to revisit this logic and consider L1_CACHE_BYTES the >> >> _minimum_ of cache line sizes in arm64

Re: [PATCH] Revert "arm64: Increase the max granular size"

2017-04-06 23:58 GMT+08:00 Catalin Marinas : > On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: >> On 4/5/2017 10:13 AM, Imran Khan wrote: >> >> We may have to revisit this logic and consider L1_CACHE_BYTES the >> >> _minimum_ of cache line sizes in arm64 systems supported by the

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: > On 4/5/2017 10:13 AM, Imran Khan wrote: > >> We may have to revisit this logic and consider L1_CACHE_BYTES the > >> _minimum_ of cache line sizes in arm64 systems supported by the kernel. > >> Do you have any benchmarks on Cavium boards

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: > On 4/5/2017 10:13 AM, Imran Khan wrote: > >> We may have to revisit this logic and consider L1_CACHE_BYTES the > >> _minimum_ of cache line sizes in arm64 systems supported by the kernel. > >> Do you have any benchmarks on Cavium boards

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/5/2017 10:13 AM, Imran Khan wrote: Hi Catalin, > Hi Catalin, > >> From: Catalin Marinas <catalin.mari...@arm.com> >> Date: Mon, Mar 21, 2016 at 10:44 PM >> Subject: Re: [PATCH] Revert "arm64: Increase the max granular size" >> To

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 4/5/2017 10:13 AM, Imran Khan wrote: Hi Catalin, > Hi Catalin, > >> From: Catalin Marinas >> Date: Mon, Mar 21, 2016 at 10:44 PM >> Subject: Re: [PATCH] Revert "arm64: Increase the max granular size" >> To: "Chalamarla, Tirumalesh&quo

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 3/21/16, 10:33 AM, "Catalin Marinas" wrote: >On Mon, Mar 21, 2016 at 05:23:01PM +, Will Deacon wrote: >> On Mon, Mar 21, 2016 at 05:14:03PM +, Catalin Marinas wrote: >> > diff --git a/arch/arm64/include/asm/cache.h >> > b/arch/arm64/include/asm/cache.h

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 3/21/16, 10:33 AM, "Catalin Marinas" wrote: >On Mon, Mar 21, 2016 at 05:23:01PM +, Will Deacon wrote: >> On Mon, Mar 21, 2016 at 05:14:03PM +, Catalin Marinas wrote: >> > diff --git a/arch/arm64/include/asm/cache.h >> > b/arch/arm64/include/asm/cache.h >> > index

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Mon, Mar 21, 2016 at 05:23:01PM +, Will Deacon wrote: > On Mon, Mar 21, 2016 at 05:14:03PM +, Catalin Marinas wrote: > > diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h > > index 5082b30bc2c0..4b5d7b27edaf 100644 > > --- a/arch/arm64/include/asm/cache.h > >

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Mon, Mar 21, 2016 at 05:23:01PM +, Will Deacon wrote: > On Mon, Mar 21, 2016 at 05:14:03PM +, Catalin Marinas wrote: > > diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h > > index 5082b30bc2c0..4b5d7b27edaf 100644 > > --- a/arch/arm64/include/asm/cache.h > >

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Mon, Mar 21, 2016 at 05:14:03PM +, Catalin Marinas wrote: > On Fri, Mar 18, 2016 at 09:05:37PM +, Chalamarla, Tirumalesh wrote: > > On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" > > >

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Mon, Mar 21, 2016 at 05:14:03PM +, Catalin Marinas wrote: > On Fri, Mar 18, 2016 at 09:05:37PM +, Chalamarla, Tirumalesh wrote: > > On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" > > > opensource.gan...@gmail.com> wrote: > > >Reverts commit 97303480753e ("arm64:

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Fri, Mar 18, 2016 at 09:05:37PM +, Chalamarla, Tirumalesh wrote: > On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" > opensource.gan...@gmail.com> wrote: > >Reverts commit 97303480753e ("arm64: Increase the

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Fri, Mar 18, 2016 at 09:05:37PM +, Chalamarla, Tirumalesh wrote: > On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" > opensource.gan...@gmail.com> wrote: > >Reverts commit 97303480753e ("arm64: Increase the max granular size"). > > > >The commit 97303480753e ("arm64:

Re: [PATCH] Revert "arm64: Increase the max granular size"

Hello, Tirumalesh: 2016-03-19 5:05 GMT+08:00 Chalamarla, Tirumalesh : > > > > > > On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" > opensource.gan...@gmail.com> wrote: >

Re: [PATCH] Revert "arm64: Increase the max granular size"

Hello, Tirumalesh: 2016-03-19 5:05 GMT+08:00 Chalamarla, Tirumalesh : > > > > > > On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" > opensource.gan...@gmail.com> wrote: > >>Reverts commit 97303480753e ("arm64: Increase the max granular size"). >> >>The commit 97303480753e

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 02:35:35PM +, Will Deacon wrote: > On Wed, Mar 16, 2016 at 02:03:35PM +, Mark Rutland wrote: > > If I understand correctly, the main reason that we need this for > > correctness is > > non-coherent DMA to/from SLAB caches. > > > > A more general approach (and more

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 02:35:35PM +, Will Deacon wrote: > On Wed, Mar 16, 2016 at 02:03:35PM +, Mark Rutland wrote: > > If I understand correctly, the main reason that we need this for > > correctness is > > non-coherent DMA to/from SLAB caches. > > > > A more general approach (and more

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Thu, Mar 17, 2016 at 09:49:51AM -0500, Timur Tabi wrote: > Catalin Marinas wrote: > >>>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

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Thu, Mar 17, 2016 at 09:49:51AM -0500, Timur Tabi wrote: > Catalin Marinas wrote: > >>>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

Re: [PATCH] Revert "arm64: Increase the max granular size"

Catalin Marinas wrote: >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

Re: [PATCH] Revert "arm64: Increase the max granular size"

Catalin Marinas wrote: >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

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 17/03/16 15:37, Catalin Marinas wrote: > On Thu, Mar 17, 2016 at 09:49:51AM -0500, Timur Tabi wrote: [...] >> Keep in mind that on an ACPI system like ours, the boot loader (UEFI in our >> case) configures the system extensively. It does a lot of things that the >> kernel would normally do

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 17/03/16 15:37, Catalin Marinas wrote: > On Thu, Mar 17, 2016 at 09:49:51AM -0500, Timur Tabi wrote: [...] >> Keep in mind that on an ACPI system like ours, the boot loader (UEFI in our >> case) configures the system extensively. It does a lot of things that the >> kernel would normally do

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 08:06:22AM -0500, Timur Tabi wrote: > Will Deacon wrote: > >You could look into making ARCH_DMA_MINALIGN a runtime value, but that > >looks like an uphill struggle to me. Alternatively, we could only warn > >if the CWG is bigger than L1_CACHE_BYTES *and* we have a

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 08:06:22AM -0500, Timur Tabi wrote: > Will Deacon wrote: > >You could look into making ARCH_DMA_MINALIGN a runtime value, but that > >looks like an uphill struggle to me. Alternatively, we could only warn > >if the CWG is bigger than L1_CACHE_BYTES *and* we have a

Re: [PATCH] Revert "arm64: Increase the max granular size"

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

Re: [PATCH] Revert "arm64: Increase the max granular size"

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

Re: [PATCH] Revert "arm64: Increase the max granular size"

Will Deacon wrote: [adding Cavium folk and Timur] On Wed, Mar 16, 2016 at 05:32:23PM +0800, Ganesh Mahendran wrote: Reverts commit 97303480753e ("arm64: Increase the max granular size"). The commit 97303480753e ("arm64: Increase the max granular size") will degrade system performente in some

Re: [PATCH] Revert "arm64: Increase the max granular size"

Will Deacon wrote: [adding Cavium folk and Timur] On Wed, Mar 16, 2016 at 05:32:23PM +0800, Ganesh Mahendran wrote: Reverts commit 97303480753e ("arm64: Increase the max granular size"). The commit 97303480753e ("arm64: Increase the max granular size") will degrade system performente in some

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 02:03:35PM +, Mark Rutland wrote: > If I understand correctly, the main reason that we need this for correctness > is > non-coherent DMA to/from SLAB caches. > > A more general approach (and more invasive, but perhaps less so than making > ARCH_DMA_MINALIGN usage

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 02:03:35PM +, Mark Rutland wrote: > If I understand correctly, the main reason that we need this for correctness > is > non-coherent DMA to/from SLAB caches. > > A more general approach (and more invasive, but perhaps less so than making > ARCH_DMA_MINALIGN usage

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" wrote: >Reverts commit 97303480753e ("arm64: Increase the max granular size"). > >The commit 97303480753e ("arm64: Increase the max

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran" wrote: >Reverts commit 97303480753e ("arm64: Increase the max granular size"). > >The commit 97303480753e ("arm64: Increase the max granular size") will >degrade system performente in some cpus. > >We test wifi network

Re: [PATCH] Revert "arm64: Increase the max granular size"

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),

Re: [PATCH] Revert "arm64: Increase the max granular size"

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),

Re: [PATCH] Revert "arm64: Increase the max granular size"

Andrew Pinski wrote: 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. Note the defconfig works correctly on T88. This thread is getting off-topic.

Re: [PATCH] Revert "arm64: Increase the max granular size"

Andrew Pinski wrote: 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. Note the defconfig works correctly on T88. This thread is getting off-topic.

Re: [PATCH] Revert "arm64: Increase the max granular size"

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

Re: [PATCH] Revert "arm64: Increase the max granular size"

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

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 08:06:22AM -0500, Timur Tabi wrote: > Will Deacon wrote: > >Unfortunately, the original patch is required to support the 128-byte L1 > >cache lines of Cavium ThunderX, so we can't simply revert it like this. > >Similarly, the desire for a single, multiplatform kernel image

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Wed, Mar 16, 2016 at 08:06:22AM -0500, Timur Tabi wrote: > Will Deacon wrote: > >Unfortunately, the original patch is required to support the 128-byte L1 > >cache lines of Cavium ThunderX, so we can't simply revert it like this. > >Similarly, the desire for a single, multiplatform kernel image

Re: [PATCH] Revert "arm64: Increase the max granular size"

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

Re: [PATCH] Revert "arm64: Increase the max granular size"

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

Re: [PATCH] Revert "arm64: Increase the max granular size"

[adding Cavium folk and Timur] On Wed, Mar 16, 2016 at 05:32:23PM +0800, Ganesh Mahendran wrote: > Reverts commit 97303480753e ("arm64: Increase the max granular size"). > > The commit 97303480753e ("arm64: Increase the max granular size") will > degrade system performente in some cpus. > > We

Re: [PATCH] Revert "arm64: Increase the max granular size"

[adding Cavium folk and Timur] On Wed, Mar 16, 2016 at 05:32:23PM +0800, Ganesh Mahendran wrote: > Reverts commit 97303480753e ("arm64: Increase the max granular size"). > > The commit 97303480753e ("arm64: Increase the max granular size") will > degrade system performente in some cpus. > > We

[PATCH] Revert "arm64: Increase the max granular size"

Reverts commit 97303480753e ("arm64: Increase the max granular size"). The commit 97303480753e ("arm64: Increase the max granular size") will degrade system performente in some cpus. We test wifi network throughput with iperf on Qualcomm msm8996 CPU: run on host: # iperf -s

[PATCH] Revert "arm64: Increase the max granular size"

Reverts commit 97303480753e ("arm64: Increase the max granular size"). The commit 97303480753e ("arm64: Increase the max granular size") will degrade system performente in some cpus. We test wifi network throughput with iperf on Qualcomm msm8996 CPU: run on host: # iperf -s