RE: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-04 Thread David Laight
From: Waiman Long > Sent: 03 May 2024 23:14 > > > On 5/3/24 17:10, David Laight wrote: > > From: Waiman Long > >> Sent: 03 May 2024 17:00 > > ... > >> David, > >> > >> Could you respin the series based on the latest upstream code? > > I've just reapplied the patches to 'master' and they all

Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread Waiman Long
On 5/3/24 17:10, David Laight wrote: From: Waiman Long Sent: 03 May 2024 17:00 ... David, Could you respin the series based on the latest upstream code? I've just reapplied the patches to 'master' and they all apply cleanly and diffing the new patches to the old ones gives no differences.

RE: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread David Laight
From: Waiman Long > Sent: 03 May 2024 17:00 ... > David, > > Could you respin the series based on the latest upstream code? I've just reapplied the patches to 'master' and they all apply cleanly and diffing the new patches to the old ones gives no differences. So I think they should still apply.

RE: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread David Laight
.linux- > foundation.org' ; 'Zeng Heng' > > Subject: Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and > per_cpu_ptr(). > > > On 12/31/23 23:14, Waiman Long wrote: > > > > On 12/31/23 16:55, David Laight wrote: > >> per_cpu_ptr() indexes

Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-05-03 Thread Waiman Long
On 12/31/23 23:14, Waiman Long wrote: On 12/31/23 16:55, David Laight 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

RE: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-01-02 Thread David Laight
From: Ingo Molnar > Sent: 02 January 2024 09:54 > > > * David Laight 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

Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-01-02 Thread Ingo Molnar
* David Laight 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

RE: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2024-01-01 Thread David Laight
From: Waiman Long > Sent: 01 January 2024 04:14 ... > You really like micro-optimization. They all add up :-) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

Re: [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2023-12-31 Thread Waiman Long
On 12/31/23 16:55, David Laight 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

[PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr().

2023-12-31 Thread David Laight
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