On Mon, Apr 01, 2019 at 08:44:14AM -0700, Paul E. McKenney wrote:
> On Mon, Apr 01, 2019 at 12:53:48PM +0200, Peter Zijlstra wrote:
> > On Fri, Mar 29, 2019 at 03:05:54PM -0700, Paul E. McKenney wrote:
> > > From Documentation/core-api/atomic_ops.rst:
> >
> > We should delete that file.
>
> Only
On Mon, Apr 01, 2019 at 12:53:48PM +0200, Peter Zijlstra wrote:
> On Fri, Mar 29, 2019 at 03:05:54PM -0700, Paul E. McKenney wrote:
> > On Fri, Mar 29, 2019 at 02:51:26PM -0700, H. Peter Anvin wrote:
> > > On 3/29/19 2:09 PM, Paul E. McKenney wrote:
> > > >>
> > > >> Note: the atomic versions of th
On Fri, Mar 29, 2019 at 9:52 PM H. Peter Anvin wrote:
>
> On 3/29/19 8:54 AM, Alexander Potapenko wrote:
> >
> >> Of course, this would force the compiler to actually compute the
> >> offset, which would slow things down. I have no idea whether this
> >> would be better or worse than just using t
On Fri, Mar 29, 2019 at 03:05:54PM -0700, Paul E. McKenney wrote:
> On Fri, Mar 29, 2019 at 02:51:26PM -0700, H. Peter Anvin wrote:
> > On 3/29/19 2:09 PM, Paul E. McKenney wrote:
> > >>
> > >> Note: the atomic versions of these functions obviously need to have
> > >> "volatile" and the clobber any
On March 29, 2019 3:05:54 PM PDT, "Paul E. McKenney"
wrote:
>On Fri, Mar 29, 2019 at 02:51:26PM -0700, H. Peter Anvin wrote:
>> On 3/29/19 2:09 PM, Paul E. McKenney wrote:
>> >>
>> >> Note: the atomic versions of these functions obviously need to
>have
>> >> "volatile" and the clobber anyway, as
On Fri, Mar 29, 2019 at 02:51:26PM -0700, H. Peter Anvin wrote:
> On 3/29/19 2:09 PM, Paul E. McKenney wrote:
> >>
> >> Note: the atomic versions of these functions obviously need to have
> >> "volatile" and the clobber anyway, as they are by definition barriers
> >> and moving memory operations ar
On 3/29/19 2:09 PM, Paul E. McKenney wrote:
>>
>> Note: the atomic versions of these functions obviously need to have
>> "volatile" and the clobber anyway, as they are by definition barriers
>> and moving memory operations around them would be a very serious error.
>
> The atomic functions that re
On Fri, Mar 29, 2019 at 01:52:33PM -0700, H. Peter Anvin wrote:
> On 3/29/19 8:54 AM, Alexander Potapenko wrote:
> >
> >> Of course, this would force the compiler to actually compute the
> >> offset, which would slow things down. I have no idea whether this
> >> would be better or worse than just
On 3/29/19 8:54 AM, Alexander Potapenko wrote:
>
>> Of course, this would force the compiler to actually compute the
>> offset, which would slow things down. I have no idea whether this
>> would be better or worse than just using the "memory" clobber.
> Just adding the "memory" clobber to clear_b
On Thu, Mar 28, 2019 at 5:22 PM Paul E. McKenney wrote:
>
> On Thu, Mar 28, 2019 at 03:14:12PM +0100, Alexander Potapenko wrote:
> > Hello,
> >
> > arch/x86/include/asm/bitops.h defines clear_bit(nr, addr) for
> > non-constant |nr| values as follows:
> >
> > void clear_bit(long nr, volatile unsign
On Thu, Mar 28, 2019 at 03:14:12PM +0100, Alexander Potapenko wrote:
> Hello,
>
> arch/x86/include/asm/bitops.h defines clear_bit(nr, addr) for
> non-constant |nr| values as follows:
>
> void clear_bit(long nr, volatile unsigned long *addr) {
> asm volatile("lock; btr %1,%0"
> : "+m"(*(vola
Hello,
arch/x86/include/asm/bitops.h defines clear_bit(nr, addr) for
non-constant |nr| values as follows:
void clear_bit(long nr, volatile unsigned long *addr) {
asm volatile("lock; btr %1,%0"
: "+m"(*(volatile long *)addr)
: "Ir" (nr));
}
(https://elixir.bootlin.com/linux/latest/sour
12 matches
Mail list logo