All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: kvm-riscv@lists.infradead.org
Subject: [PATCH v4 6/8] RISC-V: Use Zicboz in clear_page when available
Date: Thu, 09 Feb 2023 19:10:03 -0000	[thread overview]
Message-ID: <Y+VFAUZ2smkKO0EZ@spud> (raw)
In-Reply-To: <20230209152628.129914-7-ajones@ventanamicro.com>

On Thu, Feb 09, 2023 at 04:26:26PM +0100, Andrew Jones wrote:
> Using memset() to zero a 4K page takes 563 total instructions, where
> 20 are branches. clear_page(), with Zicboz and a 64 byte block size,
> takes 169 total instructions, where 4 are branches and 33 are nops.
> Even though the block size is a variable, thanks to alternatives, we
> can still implement a Duff device without having to do any preliminary
> calculations. This is achieved by taking advantage of 'vendor_id'
> being used as application-specific data for alternatives, enabling us
> to stop patching / unrolling when 4K bytes have been zeroed (we would
> loop and continue after 4K if the page size would be larger)
> 
> For 4K pages, unrolling 16 times allows block sizes of 64 and 128 to
> only loop a few times and larger block sizes to not loop at all. Since
> cbo.zero doesn't take an offset, we also need an 'add' after each
> instruction, making the loop body 112 to 160 bytes. Hopefully this
> is small enough to not cause icache misses.
> 
> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>

> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 74736b4f0624..42246bbfa532 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -280,6 +280,17 @@ void __init riscv_fill_hwcap(void)
>  #ifdef CONFIG_RISCV_ALTERNATIVE
>  static bool riscv_cpufeature_application_check(u32 feature, u16 data)
>  {
> +	switch (feature) {
> +	case RISCV_ISA_EXT_ZICBOZ:
> +		/*
> +		 * Zicboz alternative applications provide the maximum

I like the comment, rather than this being some wizardry.
I find the word "applications" to be a little unclear, perhaps, iff this
series needs a respin, this would work better as "Users of the Zicboz
alternative provide..." (or s/Users/Callers)?

> +		 * supported block size order, or zero when it doesn't
> +		 * matter. If the current block size exceeds the maximum,
> +		 * then the alternative cannot be applied.
> +		 */
> +		return data == 0 || riscv_cboz_block_size <= (1U << data);
> +	}
> +
>  	return data == 0;
>  }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kvm-riscv/attachments/20230209/5e2ac21a/attachment-0001.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org, kvm-riscv@lists.infradead.org,
	devicetree@vger.kernel.org,
	'Anup Patel ' <apatel@ventanamicro.com>,
	'Palmer Dabbelt ' <palmer@dabbelt.com>,
	'Paul Walmsley ' <paul.walmsley@sifive.com>,
	'Krzysztof Kozlowski ' <krzysztof.kozlowski+dt@linaro.org>,
	'Atish Patra ' <atishp@rivosinc.com>,
	'Heiko Stuebner ' <heiko@sntech.de>,
	'Jisheng Zhang ' <jszhang@kernel.org>,
	'Rob Herring ' <robh@kernel.org>,
	'Albert Ou ' <aou@eecs.berkeley.edu>,
	'Conor Dooley ' <conor.dooley@microchip.com>
Subject: Re: [PATCH v4 6/8] RISC-V: Use Zicboz in clear_page when available
Date: Thu, 9 Feb 2023 19:09:53 +0000	[thread overview]
Message-ID: <Y+VFAUZ2smkKO0EZ@spud> (raw)
In-Reply-To: <20230209152628.129914-7-ajones@ventanamicro.com>


[-- Attachment #1.1: Type: text/plain, Size: 2206 bytes --]

On Thu, Feb 09, 2023 at 04:26:26PM +0100, Andrew Jones wrote:
> Using memset() to zero a 4K page takes 563 total instructions, where
> 20 are branches. clear_page(), with Zicboz and a 64 byte block size,
> takes 169 total instructions, where 4 are branches and 33 are nops.
> Even though the block size is a variable, thanks to alternatives, we
> can still implement a Duff device without having to do any preliminary
> calculations. This is achieved by taking advantage of 'vendor_id'
> being used as application-specific data for alternatives, enabling us
> to stop patching / unrolling when 4K bytes have been zeroed (we would
> loop and continue after 4K if the page size would be larger)
> 
> For 4K pages, unrolling 16 times allows block sizes of 64 and 128 to
> only loop a few times and larger block sizes to not loop at all. Since
> cbo.zero doesn't take an offset, we also need an 'add' after each
> instruction, making the loop body 112 to 160 bytes. Hopefully this
> is small enough to not cause icache misses.
> 
> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>

> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 74736b4f0624..42246bbfa532 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -280,6 +280,17 @@ void __init riscv_fill_hwcap(void)
>  #ifdef CONFIG_RISCV_ALTERNATIVE
>  static bool riscv_cpufeature_application_check(u32 feature, u16 data)
>  {
> +	switch (feature) {
> +	case RISCV_ISA_EXT_ZICBOZ:
> +		/*
> +		 * Zicboz alternative applications provide the maximum

I like the comment, rather than this being some wizardry.
I find the word "applications" to be a little unclear, perhaps, iff this
series needs a respin, this would work better as "Users of the Zicboz
alternative provide..." (or s/Users/Callers)?

> +		 * supported block size order, or zero when it doesn't
> +		 * matter. If the current block size exceeds the maximum,
> +		 * then the alternative cannot be applied.
> +		 */
> +		return data == 0 || riscv_cboz_block_size <= (1U << data);
> +	}
> +
>  	return data == 0;
>  }

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org, kvm-riscv@lists.infradead.org,
	devicetree@vger.kernel.org,
	'Anup Patel ' <apatel@ventanamicro.com>,
	'Palmer Dabbelt ' <palmer@dabbelt.com>,
	'Paul Walmsley ' <paul.walmsley@sifive.com>,
	'Krzysztof Kozlowski ' <krzysztof.kozlowski+dt@linaro.org>,
	'Atish Patra ' <atishp@rivosinc.com>,
	'Heiko Stuebner ' <heiko@sntech.de>,
	'Jisheng Zhang ' <jszhang@kernel.org>,
	'Rob Herring ' <robh@kernel.org>,
	'Albert Ou ' <aou@eecs.berkeley.edu>,
	'Conor Dooley ' <conor.dooley@microchip.com>
Subject: Re: [PATCH v4 6/8] RISC-V: Use Zicboz in clear_page when available
Date: Thu, 9 Feb 2023 19:09:53 +0000	[thread overview]
Message-ID: <Y+VFAUZ2smkKO0EZ@spud> (raw)
In-Reply-To: <20230209152628.129914-7-ajones@ventanamicro.com>

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

On Thu, Feb 09, 2023 at 04:26:26PM +0100, Andrew Jones wrote:
> Using memset() to zero a 4K page takes 563 total instructions, where
> 20 are branches. clear_page(), with Zicboz and a 64 byte block size,
> takes 169 total instructions, where 4 are branches and 33 are nops.
> Even though the block size is a variable, thanks to alternatives, we
> can still implement a Duff device without having to do any preliminary
> calculations. This is achieved by taking advantage of 'vendor_id'
> being used as application-specific data for alternatives, enabling us
> to stop patching / unrolling when 4K bytes have been zeroed (we would
> loop and continue after 4K if the page size would be larger)
> 
> For 4K pages, unrolling 16 times allows block sizes of 64 and 128 to
> only loop a few times and larger block sizes to not loop at all. Since
> cbo.zero doesn't take an offset, we also need an 'add' after each
> instruction, making the loop body 112 to 160 bytes. Hopefully this
> is small enough to not cause icache misses.
> 
> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>

> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 74736b4f0624..42246bbfa532 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -280,6 +280,17 @@ void __init riscv_fill_hwcap(void)
>  #ifdef CONFIG_RISCV_ALTERNATIVE
>  static bool riscv_cpufeature_application_check(u32 feature, u16 data)
>  {
> +	switch (feature) {
> +	case RISCV_ISA_EXT_ZICBOZ:
> +		/*
> +		 * Zicboz alternative applications provide the maximum

I like the comment, rather than this being some wizardry.
I find the word "applications" to be a little unclear, perhaps, iff this
series needs a respin, this would work better as "Users of the Zicboz
alternative provide..." (or s/Users/Callers)?

> +		 * supported block size order, or zero when it doesn't
> +		 * matter. If the current block size exceeds the maximum,
> +		 * then the alternative cannot be applied.
> +		 */
> +		return data == 0 || riscv_cboz_block_size <= (1U << data);
> +	}
> +
>  	return data == 0;
>  }

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-02-09 19:10 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09 15:26 [PATCH v4 0/8] RISC-V: Apply Zicboz to clear_page Andrew Jones
2023-02-09 15:26 ` Andrew Jones
2023-02-09 15:26 ` Andrew Jones
2023-02-09 15:26 ` [PATCH v4 1/8] RISC-V: alternatives: Support patching multiple insns in assembly Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 18:02   ` Conor Dooley
2023-02-09 18:03     ` Conor Dooley
2023-02-09 18:02     ` Conor Dooley
2023-02-09 15:26 ` [PATCH v4 2/8] RISC-V: Factor out body of riscv_init_cbom_blocksize loop Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26 ` [PATCH v4 3/8] dt-bindings: riscv: Document cboz-block-size Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26 ` [PATCH v4 4/8] RISC-V: Add Zicboz detection and block size parsing Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26 ` [PATCH v4 5/8] RISC-V: cpufeature: Put vendor_id to work Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 19:04   ` Conor Dooley
2023-02-09 19:05     ` Conor Dooley
2023-02-09 19:04     ` Conor Dooley
2023-02-10  7:58     ` Andrew Jones
2023-02-10  7:58       ` Andrew Jones
2023-02-10  7:58       ` Andrew Jones
2023-02-10 20:29       ` Conor Dooley
2023-02-10 20:29         ` Conor Dooley
2023-02-10 20:29         ` Conor Dooley
2023-02-12 16:26         ` Andrew Jones
2023-02-12 16:26           ` Andrew Jones
2023-02-12 16:26           ` Andrew Jones
2023-02-09 15:26 ` [PATCH v4 6/8] RISC-V: Use Zicboz in clear_page when available Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 19:09   ` Conor Dooley [this message]
2023-02-09 19:10     ` Conor Dooley
2023-02-09 19:09     ` Conor Dooley
2023-02-10  8:05     ` Andrew Jones
2023-02-10  8:05       ` Andrew Jones
2023-02-10  8:05       ` Andrew Jones
2023-02-10  9:04       ` Conor Dooley
2023-02-10  9:05         ` Conor Dooley
2023-02-10  9:04         ` Conor Dooley
2023-02-17 10:18   ` Ben Dooks
2023-02-17 10:18     ` Ben Dooks
2023-02-17 10:18     ` Ben Dooks
2023-02-17 10:50     ` Ben Dooks
2023-02-17 10:50       ` Ben Dooks
2023-02-17 10:50       ` Ben Dooks
2023-02-17 12:29       ` Andrew Jones
2023-02-17 12:29         ` Andrew Jones
2023-02-17 12:29         ` Andrew Jones
2023-02-20 18:43         ` Ben Dooks
2023-02-20 18:43           ` Ben Dooks
2023-02-20 18:43           ` Ben Dooks
2023-02-20 19:24           ` Andrew Jones
2023-02-20 19:24             ` Andrew Jones
2023-02-20 19:24             ` Andrew Jones
2023-02-17 12:44     ` Andrew Jones
2023-02-17 12:44       ` Andrew Jones
2023-02-17 12:44       ` Andrew Jones
2023-02-09 15:26 ` [PATCH v4 7/8] RISC-V: KVM: Provide UAPI for Zicboz block size Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26 ` [PATCH v4 8/8] RISC-V: KVM: Expose Zicboz to the guest Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 15:26   ` Andrew Jones
2023-02-09 17:45 ` [PATCH v4 0/8] RISC-V: Apply Zicboz to clear_page Conor Dooley
2023-02-09 17:45   ` Conor Dooley
2023-02-09 17:45   ` Conor Dooley

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=Y+VFAUZ2smkKO0EZ@spud \
    --to=conor@kernel.org \
    --cc=kvm-riscv@lists.infradead.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.