On Wednesday 09 March 2016 05:10 PM, Peter Zijlstra wrote:
> ---
> Subject: bitops: Do not default to __clear_bit() for __clear_bit_unlock()
>
> __clear_bit_unlock() is a special little snowflake. While it carries the
> non-atomic '__' prefix, it is specifically documented to pair with
> test_and
On Thu, Mar 10, 2016 at 11:21:21AM +0530, Vineet Gupta wrote:
> On Wednesday 09 March 2016 08:21 PM, Peter Zijlstra wrote:
> >> But in SLUB: bit_spin_lock() + __bit_spin_unlock() is acceptable ? How so
> >> (ignoring the performance thing for discussion sake, which is a side
> >> effect of
> >> th
On Wednesday 09 March 2016 08:21 PM, Peter Zijlstra wrote:
>> But in SLUB: bit_spin_lock() + __bit_spin_unlock() is acceptable ? How so
>> (ignoring the performance thing for discussion sake, which is a side effect
>> of
>> this implementation).
>
> The sort answer is: Per definition. They are de
On Wed, Mar 09, 2016 at 06:52:45PM +0530, Vineet Gupta wrote:
> On Wednesday 09 March 2016 03:43 PM, Peter Zijlstra wrote:
> >> There is clearly a problem in slub code that it is pairing a
> >> test_and_set_bit()
> >> with a __clear_bit(). Latter can obviously clobber former if they are not
> >>
On Wednesday 09 March 2016 03:43 PM, Peter Zijlstra wrote:
>> There is clearly a problem in slub code that it is pairing a
>> test_and_set_bit()
>> with a __clear_bit(). Latter can obviously clobber former if they are not a
>> single
>> instruction each unlike x86 or they use llock/scond kind of
On Wed, Mar 09, 2016 at 05:23:26PM +0530, Vineet Gupta wrote:
> > I did not follow through the maze, I think the few archs implementing
> > this simply do not include this file at all.
> >
> > I'll let the first person that cares about this worry about that :-)
>
> Ok - that's be me :-) although
On Wednesday 09 March 2016 05:10 PM, Peter Zijlstra wrote:
> On Wed, Mar 09, 2016 at 04:30:31PM +0530, Vineet Gupta wrote:
>> FWIW, could we add some background to commit log, specifically what prompted
>> this.
>> Something like below...
>
> Sure.. find below.
>
>>> +++ b/include/asm-generic/bi
On Wed, Mar 09, 2016 at 04:30:31PM +0530, Vineet Gupta wrote:
> FWIW, could we add some background to commit log, specifically what prompted
> this.
> Something like below...
Sure.. find below.
> > +++ b/include/asm-generic/bitops/lock.h
> > @@ -29,16 +29,16 @@ do {
On Wednesday 09 March 2016 04:01 PM, Peter Zijlstra wrote:
> On Wed, Mar 09, 2016 at 11:13:49AM +0100, Peter Zijlstra wrote:
>> ---
>> Subject: bitops: Do not default to __clear_bit() for __clear_bit_unlock()
>>
>> __clear_bit_unlock() is a special little snowflake. While it carries the
>> non-atom
On Wednesday 09 March 2016 03:43 PM, Peter Zijlstra wrote:
>>> If you take the lock in __bit_spin_unlock
>>> then the race cannot happen.
>>
>> Of course it won't but that means we penalize all non atomic callers of the
>> API
>> with a superfluous spinlock which is not require din first place giv
On Wed, Mar 09, 2016 at 11:13:49AM +0100, Peter Zijlstra wrote:
> ---
> Subject: bitops: Do not default to __clear_bit() for __clear_bit_unlock()
>
> __clear_bit_unlock() is a special little snowflake. While it carries the
> non-atomic '__' prefix, it is specifically documented to pair with
> test
On Wed, Mar 09, 2016 at 12:13:16PM +0530, Vineet Gupta wrote:
> +CC linux-arch, parisc folks, PeterZ
>
> On Wednesday 09 March 2016 02:10 AM, Christoph Lameter wrote:
> > On Tue, 8 Mar 2016, Vineet Gupta wrote:
> >
> >> # set the bit
> >> 80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked
+CC linux-arch, parisc folks, PeterZ
On Wednesday 09 March 2016 02:10 AM, Christoph Lameter wrote:
> On Tue, 8 Mar 2016, Vineet Gupta wrote:
>
>> # set the bit
>> 80543b8e:ld_s r2,[r13,0] <--- (A) Finds PG_locked is set
>> 80543b90:or r3,r2,1<--- (B) other core unlocks r
On Tue, 8 Mar 2016, Vineet Gupta wrote:
> # set the bit
> 80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked is set
> 80543b90: or r3,r2,1<--- (B) other core unlocks right here
> 80543b94: st_s r3,[r13,0] <--- (C) sets PG_locked (overwrites
> unlock)
Duh. Gues
On Tuesday 08 March 2016 08:30 PM, Christoph Lameter wrote:
> On Tue, 8 Mar 2016, Vineet Gupta wrote:
>
>> This in turn happened because slab_unlock() doesn't serialize properly
>> (doesn't use atomic clear) with a concurrent running
>> slab_lock()->test_and_set_bit()
>
> This is intentional beca
On 03/08/2016 03:30 PM, Vineet Gupta wrote:
> We observed livelocks on ARC SMP setup when running hackbench with SLUB.
> This hardware configuration lacks atomic instructions (LLOCK/SCOND) thus
> kernel resorts to a central @smp_bitops_lock to protect any R-M-W ops
> suh as test_and_set_bit()
Soun
On Tue, 8 Mar 2016, Vineet Gupta wrote:
> This in turn happened because slab_unlock() doesn't serialize properly
> (doesn't use atomic clear) with a concurrent running
> slab_lock()->test_and_set_bit()
This is intentional because of the increased latency of atomic
instructions. Why would the unlo
We observed livelocks on ARC SMP setup when running hackbench with SLUB.
This hardware configuration lacks atomic instructions (LLOCK/SCOND) thus
kernel resorts to a central @smp_bitops_lock to protect any R-M-W ops
suh as test_and_set_bit()
The spinlock itself is implemented using Atomic [EX]chan
18 matches
Mail list logo
