Hi Greg,
On 2018/10/13 15:30, Greg Kroah-Hartman wrote:
> On Sat, Oct 13, 2018 at 03:22:08PM +0800, Gao Xiang wrote:
>> Hi Greg,
>>
>> On 2018/10/13 15:04, Greg Kroah-Hartman wrote:
>>> On Sat, Oct 13, 2018 at 02:47:29PM +0800, Gao Xiang wrote:
It is better to use smp_cond_load_relaxed instea
On Sat, Oct 13, 2018 at 03:22:08PM +0800, Gao Xiang wrote:
> Hi Greg,
>
> On 2018/10/13 15:04, Greg Kroah-Hartman wrote:
> > On Sat, Oct 13, 2018 at 02:47:29PM +0800, Gao Xiang wrote:
> >> It is better to use smp_cond_load_relaxed instead
> >> of busy waiting for bit_spinlock.
> >
> > Why? I thi
On 2018/10/13 15:22, Gao Xiang wrote:
> For other architectures like x86/arm64, I think they could implement
> smp_cond_load_* later.
Sorry about that, I mean "amd64".
Actually I don't have performance numbers to proof that now. I think
it really depends on the detailed architecture hardware i
Hi Greg,
On 2018/10/13 15:04, Greg Kroah-Hartman wrote:
> On Sat, Oct 13, 2018 at 02:47:29PM +0800, Gao Xiang wrote:
>> It is better to use smp_cond_load_relaxed instead
>> of busy waiting for bit_spinlock.
>
> Why? I think we need some kind of "proof" that this is true before
> being able to ac
On Sat, Oct 13, 2018 at 02:47:29PM +0800, Gao Xiang wrote:
> It is better to use smp_cond_load_relaxed instead
> of busy waiting for bit_spinlock.
Why? I think we need some kind of "proof" that this is true before
being able to accept a patch like this, don't you agree?
thanks,
greg k-h
It is better to use smp_cond_load_relaxed instead
of busy waiting for bit_spinlock.
Signed-off-by: Gao Xiang
---
include/linux/bit_spinlock.h | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/include/linux/bit_spinlock.h b/include/linux/bit_spinlock.h
ind
6 matches
Mail list logo
