All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Gavin Shan <gshan@redhat.com>
Cc: mark.rutland@arm.com, anshuman.khandual@arm.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	shan.gavin@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm64/mm: Enable color zero pages
Date: Wed, 16 Sep 2020 11:46:38 +0100	[thread overview]
Message-ID: <77dcab5a-b5f2-a67c-6157-71a5a53db5de@arm.com> (raw)
In-Reply-To: <20200916082819.GB27496@willie-the-truck>

On 2020-09-16 09:28, Will Deacon wrote:
> On Wed, Sep 16, 2020 at 01:25:23PM +1000, Gavin Shan wrote:
>> This enables color zero pages by allocating contigous page frames
>> for it. The number of pages for this is determined by L1 dCache
>> (or iCache) size, which is probbed from the hardware.
>>
>>     * Add cache_total_size() to return L1 dCache (or iCache) size
>>
>>     * Implement setup_zero_pages(), which is called after the page
>>       allocator begins to work, to allocate the contigous pages
>>       needed by color zero page.
>>
>>     * Reworked ZERO_PAGE() and define __HAVE_COLOR_ZERO_PAGE.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>> ---
>>   arch/arm64/include/asm/cache.h   | 22 ++++++++++++++++++++
>>   arch/arm64/include/asm/pgtable.h |  9 ++++++--
>>   arch/arm64/kernel/cacheinfo.c    | 34 +++++++++++++++++++++++++++++++
>>   arch/arm64/mm/init.c             | 35 ++++++++++++++++++++++++++++++++
>>   arch/arm64/mm/mmu.c              |  7 -------
>>   5 files changed, 98 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
>> index a4d1b5f771f6..420e9dde2c51 100644
>> --- a/arch/arm64/include/asm/cache.h
>> +++ b/arch/arm64/include/asm/cache.h
>> @@ -39,6 +39,27 @@
>>   #define CLIDR_LOC(clidr)	(((clidr) >> CLIDR_LOC_SHIFT) & 0x7)
>>   #define CLIDR_LOUIS(clidr)	(((clidr) >> CLIDR_LOUIS_SHIFT) & 0x7)
>>   
>> +#define CSSELR_TND_SHIFT	4
>> +#define CSSELR_TND_MASK		(UL(1) << CSSELR_TND_SHIFT)
>> +#define CSSELR_LEVEL_SHIFT	1
>> +#define CSSELR_LEVEL_MASK	(UL(7) << CSSELR_LEVEL_SHIFT)
>> +#define CSSELR_IND_SHIFT	0
>> +#define CSSERL_IND_MASK		(UL(1) << CSSELR_IND_SHIFT)
>> +
>> +#define CCSIDR_64_LS_SHIFT	0
>> +#define CCSIDR_64_LS_MASK	(UL(7) << CCSIDR_64_LS_SHIFT)
>> +#define CCSIDR_64_ASSOC_SHIFT	3
>> +#define CCSIDR_64_ASSOC_MASK	(UL(0x1FFFFF) << CCSIDR_64_ASSOC_SHIFT)
>> +#define CCSIDR_64_SET_SHIFT	32
>> +#define CCSIDR_64_SET_MASK	(UL(0xFFFFFF) << CCSIDR_64_SET_SHIFT)
>> +
>> +#define CCSIDR_32_LS_SHIFT	0
>> +#define CCSIDR_32_LS_MASK	(UL(7) << CCSIDR_32_LS_SHIFT)
>> +#define CCSIDR_32_ASSOC_SHIFT	3
>> +#define CCSIDR_32_ASSOC_MASK	(UL(0x3FF) << CCSIDR_32_ASSOC_SHIFT)
>> +#define CCSIDR_32_SET_SHIFT	13
>> +#define CCSIDR_32_SET_MASK	(UL(0x7FFF) << CCSIDR_32_SET_SHIFT)
> 
> I don't think we should be inferring cache structure from these register
> values. The Arm ARM helpfully says:
> 
>    | You cannot make any inference about the actual sizes of caches based
>    | on these parameters.
> 
> so we need to take the topology information from elsewhere.

Yes, these represent parameters for the low-level cache maintenance by 
set/way instructions, and nothing more. There are definitely cases where 
they do not reflect the underlying cache structure (commit 793acf870ea3 
is an obvious first call).

Robin.

> But before we get into that, can you justify why we need to do this at all,
> please? Do you have data to show the benefit of adding this complexity?
> 
> Cheers,
> 
> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Gavin Shan <gshan@redhat.com>
Cc: mark.rutland@arm.com, anshuman.khandual@arm.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	shan.gavin@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm64/mm: Enable color zero pages
Date: Wed, 16 Sep 2020 11:46:38 +0100	[thread overview]
Message-ID: <77dcab5a-b5f2-a67c-6157-71a5a53db5de@arm.com> (raw)
In-Reply-To: <20200916082819.GB27496@willie-the-truck>

On 2020-09-16 09:28, Will Deacon wrote:
> On Wed, Sep 16, 2020 at 01:25:23PM +1000, Gavin Shan wrote:
>> This enables color zero pages by allocating contigous page frames
>> for it. The number of pages for this is determined by L1 dCache
>> (or iCache) size, which is probbed from the hardware.
>>
>>     * Add cache_total_size() to return L1 dCache (or iCache) size
>>
>>     * Implement setup_zero_pages(), which is called after the page
>>       allocator begins to work, to allocate the contigous pages
>>       needed by color zero page.
>>
>>     * Reworked ZERO_PAGE() and define __HAVE_COLOR_ZERO_PAGE.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>> ---
>>   arch/arm64/include/asm/cache.h   | 22 ++++++++++++++++++++
>>   arch/arm64/include/asm/pgtable.h |  9 ++++++--
>>   arch/arm64/kernel/cacheinfo.c    | 34 +++++++++++++++++++++++++++++++
>>   arch/arm64/mm/init.c             | 35 ++++++++++++++++++++++++++++++++
>>   arch/arm64/mm/mmu.c              |  7 -------
>>   5 files changed, 98 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
>> index a4d1b5f771f6..420e9dde2c51 100644
>> --- a/arch/arm64/include/asm/cache.h
>> +++ b/arch/arm64/include/asm/cache.h
>> @@ -39,6 +39,27 @@
>>   #define CLIDR_LOC(clidr)	(((clidr) >> CLIDR_LOC_SHIFT) & 0x7)
>>   #define CLIDR_LOUIS(clidr)	(((clidr) >> CLIDR_LOUIS_SHIFT) & 0x7)
>>   
>> +#define CSSELR_TND_SHIFT	4
>> +#define CSSELR_TND_MASK		(UL(1) << CSSELR_TND_SHIFT)
>> +#define CSSELR_LEVEL_SHIFT	1
>> +#define CSSELR_LEVEL_MASK	(UL(7) << CSSELR_LEVEL_SHIFT)
>> +#define CSSELR_IND_SHIFT	0
>> +#define CSSERL_IND_MASK		(UL(1) << CSSELR_IND_SHIFT)
>> +
>> +#define CCSIDR_64_LS_SHIFT	0
>> +#define CCSIDR_64_LS_MASK	(UL(7) << CCSIDR_64_LS_SHIFT)
>> +#define CCSIDR_64_ASSOC_SHIFT	3
>> +#define CCSIDR_64_ASSOC_MASK	(UL(0x1FFFFF) << CCSIDR_64_ASSOC_SHIFT)
>> +#define CCSIDR_64_SET_SHIFT	32
>> +#define CCSIDR_64_SET_MASK	(UL(0xFFFFFF) << CCSIDR_64_SET_SHIFT)
>> +
>> +#define CCSIDR_32_LS_SHIFT	0
>> +#define CCSIDR_32_LS_MASK	(UL(7) << CCSIDR_32_LS_SHIFT)
>> +#define CCSIDR_32_ASSOC_SHIFT	3
>> +#define CCSIDR_32_ASSOC_MASK	(UL(0x3FF) << CCSIDR_32_ASSOC_SHIFT)
>> +#define CCSIDR_32_SET_SHIFT	13
>> +#define CCSIDR_32_SET_MASK	(UL(0x7FFF) << CCSIDR_32_SET_SHIFT)
> 
> I don't think we should be inferring cache structure from these register
> values. The Arm ARM helpfully says:
> 
>    | You cannot make any inference about the actual sizes of caches based
>    | on these parameters.
> 
> so we need to take the topology information from elsewhere.

Yes, these represent parameters for the low-level cache maintenance by 
set/way instructions, and nothing more. There are definitely cases where 
they do not reflect the underlying cache structure (commit 793acf870ea3 
is an obvious first call).

Robin.

> But before we get into that, can you justify why we need to do this at all,
> please? Do you have data to show the benefit of adding this complexity?
> 
> Cheers,
> 
> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

  reply	other threads:[~2020-09-16 10:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16  3:25 [PATCH 0/2] arm64/mm: Enable color zero pages Gavin Shan
2020-09-16  3:25 ` Gavin Shan
2020-09-16  3:25 ` [PATCH 1/2] arm64/mm: Introduce zero PGD table Gavin Shan
2020-09-16  3:25   ` Gavin Shan
2020-09-16  3:25 ` [PATCH 2/2] arm64/mm: Enable color zero pages Gavin Shan
2020-09-16  3:25   ` Gavin Shan
2020-09-16  8:28   ` Will Deacon
2020-09-16  8:28     ` Will Deacon
2020-09-16 10:46     ` Robin Murphy [this message]
2020-09-16 10:46       ` Robin Murphy
2020-09-17  4:36       ` Gavin Shan
2020-09-17  4:36         ` Gavin Shan
2020-09-17  3:35     ` Gavin Shan
2020-09-17  3:35       ` Gavin Shan
2020-09-17 10:22       ` Robin Murphy
2020-09-17 10:22         ` Robin Murphy
2020-09-21  2:56         ` Gavin Shan
2020-09-21  2:56           ` Gavin Shan
2020-09-21 12:40           ` Anshuman Khandual
2020-09-21 12:40             ` Anshuman Khandual
2020-09-22 12:39             ` Gavin Shan
2020-09-22 12:39               ` Gavin Shan
2020-09-18 12:10   ` kernel test robot
2020-09-18 12:10     ` kernel test robot
2020-09-18 12:10     ` kernel test robot

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=77dcab5a-b5f2-a67c-6157-71a5a53db5de@arm.com \
    --to=robin.murphy@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=gshan@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=shan.gavin@gmail.com \
    --cc=will@kernel.org \
    /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: link
Be 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.