linux-kernel - Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZZPdUv6uRvqXlyYo@gmail.com>
Date: Tue, 2 Jan 2024 10:54:26 +0100
From: Ingo Molnar <mingo@...nel.org>
To: David Laight <David.Laight@...lab.com>
Cc: "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	"'peterz@...radead.org'" <peterz@...radead.org>,
	"'longman@...hat.com'" <longman@...hat.com>,
	"'mingo@...hat.com'" <mingo@...hat.com>,
	"'will@...nel.org'" <will@...nel.org>,
	"'boqun.feng@...il.com'" <boqun.feng@...il.com>,
	'Linus Torvalds' <torvalds@...ux-foundation.org>,
	"'virtualization@...ts.linux-foundation.org'" <virtualization@...ts.linux-foundation.org>,
	'Zeng Heng' <zengheng4@...wei.com>
Subject: Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and
 per_cpu_ptr().


* David Laight <David.Laight@...LAB.COM> wrote:

> per_cpu_ptr() indexes __per_cpu_offset[] with the cpu number.
> This requires the cpu number be 64bit.
> However the value is osq_lock() comes from a 32bit xchg() and there
> isn't a way of telling gcc the high bits are zero (they are) so
> there will always be an instruction to clear the high bits.
> 
> The cpu number is also offset by one (to make the initialiser 0)
> It seems to be impossible to get gcc to convert __per_cpu_offset[cpu_p1 - 1]
> into (__per_cpu_offset - 1)[cpu_p1] (transferring the offset to the address).
> 
> Converting the cpu number to 32bit unsigned prior to the decrement means
> that gcc knows the decrement has set the high bits to zero and doesn't
> add a register-register move (or cltq) to zero/sign extend the value.
> 
> Not massive but saves two instructions.
> 
> Signed-off-by: David Laight <david.laight@...lab.com>
> ---
>  kernel/locking/osq_lock.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> index 35bb99e96697..37a4fa872989 100644
> --- a/kernel/locking/osq_lock.c
> +++ b/kernel/locking/osq_lock.c
> @@ -29,11 +29,9 @@ static inline int encode_cpu(int cpu_nr)
>  	return cpu_nr + 1;
>  }
>  
> -static inline struct optimistic_spin_node *decode_cpu(int encoded_cpu_val)
> +static inline struct optimistic_spin_node *decode_cpu(unsigned int encoded_cpu_val)
>  {
> -	int cpu_nr = encoded_cpu_val - 1;
> -
> -	return per_cpu_ptr(&osq_node, cpu_nr);
> +	return per_cpu_ptr(&osq_node, encoded_cpu_val - 1);

So why do we 'encode' the CPU number to begin with?

Why not use -1 as the special value? Checks for negative values 
generates similarly fast machine code compared to checking for 0, if 
the value is also used (which it is in most cases here). What am I 
missing? We seem to be going through a lot of unnecessary hoops, and 
some of that is in the runtime path.

Thanks,

	Ingo