On Sat, Jun 18, 2016 at 04:46:20PM +0800, Boqun Feng wrote:
> On Fri, Jun 17, 2016 at 02:17:27PM -0400, Waiman Long wrote:
> > keep the xchg() function as it is or use smp_store_release(>locked,
> > 1). So which one is a better alternative for ARM or PPC?
> >
>
> For PPC, I think xchg_release()
Hi guys,
On Thu, Jun 16, 2016 at 10:19:51AM +0800, Boqun Feng wrote:
> On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote:
> > On 06/15/2016 04:04 AM, Boqun Feng wrote:
> > > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> > > > @@ -198,7 +198,7 @@ void osq_unlock(struct
On Fri, Jun 17, 2016 at 11:26:41AM -0400, Waiman Long wrote:
> On 06/16/2016 08:48 PM, Boqun Feng wrote:
> >On Thu, Jun 16, 2016 at 05:35:54PM -0400, Waiman Long wrote:
> >>If you look into the actual code:
> >>
> >> next = xchg_release(>next, NULL);
> >> if (next) {
> >>
On Mon, May 22, 2017 at 11:11:33PM +0200, Thomas Gleixner wrote:
> On Mon, 15 May 2017, Will Deacon wrote:
> > On Mon, May 15, 2017 at 03:07:42PM +0200, Jiri Slaby wrote:
> > > There is code duplicated over all architecture's headers for
> > > futex_atomic_op_inuser. Na
Hi Paul,
On Tue, Oct 03, 2017 at 12:11:10PM -0700, Paul E. McKenney wrote:
> On Fri, Sep 29, 2017 at 05:33:49PM +0100, Will Deacon wrote:
> > On Fri, Sep 29, 2017 at 09:29:39AM -0700, Paul E. McKenney wrote:
> > > On Fri, Sep 29, 2017 at 10:08:43AM +0100, Will Deacon wrote:
>
On Thu, Sep 28, 2017 at 05:58:30PM -0700, Paul E. McKenney wrote:
> On Fri, Sep 29, 2017 at 07:59:09AM +1300, Michael Cree wrote:
> > On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote:
> >
On Fri, Sep 29, 2017 at 09:29:39AM -0700, Paul E. McKenney wrote:
> On Fri, Sep 29, 2017 at 10:08:43AM +0100, Will Deacon wrote:
> > On Thu, Sep 28, 2017 at 05:58:30PM -0700, Paul E. McKenney wrote:
> > > On Fri, Sep 29, 2017 at 07:59:09AM +1300, Michael Cree wrote:
> >
On Mon, Oct 23, 2017 at 10:13:12AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 23, 2017 at 09:59:21PM +1300, Michael Cree wrote:
> > On Fri, Oct 20, 2017 at 12:48:32PM -0700, Paul E. McKenney wrote:
> > > Do any of the DEC Alpha systems that run recent kernels have InfiniBand?
> > > Given my
On Wed, Aug 22, 2018 at 03:56:28PM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 22 Aug 2018, Sinan Kaya wrote:
>
> > On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
> > > If ARM guarantees that the accesses to a given device are not reordered -
> > > then the barriers in readl and writel are
On Tue, Feb 27, 2018 at 09:08:31PM +0100, Andrea Parri wrote:
> [+ Will]
>
> I'm not sure how this happened; Will, you at least figure as Reported-by: ;-)
Thanks, this looks better to me. Have you build an Alpha kernel to check
that the various cmpxchg variants are producing the expected asm?
nsistent
>with the majority and results in userspace perf retrying without
>exclusion.
>
> All drivers touched by this patchset have been compile tested.
For the bits under arch/arm/ and drivers/perf:
Acked-by: Will Deacon
Note that I've queued the TX2 uncore PMU for 4.21 [
/perf/thunderx2_pmu.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
Acked-by: Will Deacon
Thanks for fixing this up.
Will
On Thu, Jan 10, 2019 at 05:24:27PM +0100, Arnd Bergmann wrote:
> A couple of architectures including arm64 already implement the
> kexec_file_load system call, on many others we have assigned a system
> call number for it, but not implemented it yet.
>
> Adding the number in arch/arm/ lets us use
On Thu, Jan 10, 2019 at 05:24:26PM +0100, Arnd Bergmann wrote:
> The migrate_pages system call has an assigned number on all architectures
> except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
> Fix warning: #warning syscall migrate_pages not implemented"), it was
> intentionally
On Wed, Feb 27, 2019 at 12:12:51PM -0500, Mikulas Patocka wrote:
>
>
> On Tue, 26 Feb 2019, Linus Torvalds wrote:
>
> > Does anybody see any worries with the "just move the mb() earlier in
> > the ioread functions" model?
> >
> > Linus
>
> It used to be like that and it worked.
>
>
Hi Maciej,
On Wed, Feb 27, 2019 at 06:49:57PM +, Maciej W. Rozycki wrote:
> On Tue, 26 Feb 2019, Will Deacon wrote:
>
> > > If they are the same device (just different data ports), I'd
> > > *definitely* expect them to be ordered.
> > >
> &
On Wed, Feb 13, 2019 at 05:00:17PM -0500, Waiman Long wrote:
> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> it generate slightly better code.
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>:
lpha/include/asm/rwsem.h
> delete mode 100644 arch/ia64/include/asm/rwsem.h
> delete mode 100644 arch/x86/include/asm/rwsem.h
> delete mode 100644 arch/x86/lib/rwsem.S
> delete mode 100644 include/asm-generic/rwsem.h
Looks like a nice cleanup, thanks:
Acked-by: Will Deacon
Will
-
> kernel/locking/rwsem.h | 3 -
> 31 files changed, 2 insertions(+), 520 deletions(-)
> delete mode 100644 include/linux/rwsem-spinlock.h
> delete mode 100644 kernel/locking/rwsem-spinlock.c
Another nice cleanup, and it looks like the optimistic spinning in the xadd
implementation is predicated on ARCH_SUPPORTS_ATOMIC_RMW, so we're all good
there too.
Acked-by: Will Deacon
Will
irely clear to me from the commit
> > message; `mb' is a barrier and not means for a delay), then we need to
> > find a away for `iowriteX' to tell port I/O and MMIO accesses apart and
> > only apply the barrier for the former kind.
>
> Will Deacon is in the proces
On Tue, Feb 26, 2019 at 10:43:24AM -0800, Linus Torvalds wrote:
> On Tue, Feb 26, 2019 at 10:38 AM Will Deacon wrote:
> >
> > That makes sense to me for this Alpha-specific case, but in general I
> > don't think we require that I/O accesses to different endpoints are
>
On Tue, Feb 26, 2019 at 10:12:03AM -0800, Linus Torvalds wrote:
> On Tue, Feb 26, 2019 at 9:52 AM Maciej W. Rozycki
> wrote:
> >
> > The thing is taking for example `ioreadX' and `iowriteX' we have `mb'
> > before a write and `mb' after a read. So if we do say (addresses are
> > arbitrary for
On Fri, Feb 15, 2019 at 01:58:34PM -0500, Waiman Long wrote:
> On 02/15/2019 01:40 PM, Will Deacon wrote:
> > On Thu, Feb 14, 2019 at 11:37:15AM +0100, Peter Zijlstra wrote:
> >> On Wed, Feb 13, 2019 at 05:00:14PM -0500, Waiman Long wrote:
> >>> v4:
> >>&g
On Thu, Feb 14, 2019 at 11:33:33AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
> > Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> > it generate slightly better code.
> >
> > Before this patch, down_read_trylock:
> >
> >
On Thu, Feb 14, 2019 at 10:09:44AM -0800, Linus Torvalds wrote:
> On Thu, Feb 14, 2019 at 9:51 AM Linus Torvalds
> wrote:
> >
> > The arm64 numbers scaled horribly even before, and that's because
> > there is too much ping-pong, and it's probably because there is no
> > "stickiness" to the
On Thu, Feb 14, 2019 at 11:37:15AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 05:00:14PM -0500, Waiman Long wrote:
> > v4:
> > - Remove rwsem-spinlock.c and make all archs use rwsem-xadd.c.
> >
> > v3:
> > - Optimize __down_read_trylock() for the uncontended case as suggested
> >
On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > Sounds good to me - I've merged this patch, will push it out after
> > testing.
>
> Based on Peter's feedback I'm delaying this - performance testing on at
> least one key ll/sc arch would be nice
Hi Christoph,
On Fri, Aug 30, 2019 at 06:05:15PM +0200, Christoph Hellwig wrote:
> On Mon, Aug 19, 2019 at 08:36:02AM +0100, Will Deacon wrote:
> > On Sat, Aug 17, 2019 at 09:32:46AM +0200, Christoph Hellwig wrote:
> > > No need to indirect iounmap for arm64.
> > >
>
last ALIGN directive into the
RO_DATA definition too? Given that we want to map the thing read-only, it
really has to be aligned either side.
Anyway, that's only a nit, so:
Acked-by: Will Deacon
Will
P.S. Please CC the arm64 maintainers on arm64 patches -- I nearly missed
this one!
. = ALIGN((align)); \
I had to read this one to understand the later arm64 change. It looks
fine to me, so:
Acked-by: Will Deacon
Will
Hi Michael,
On Wed, Apr 03, 2019 at 01:47:50PM +1100, Michael Ellerman wrote:
> Arnd Bergmann writes:
> > diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
> > b/arch/powerpc/kernel/syscalls/syscall.tbl
> > index b18abb0c3dae..00f5a63c8d9a 100644
> > ---
Hi Jens,
On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
> On 4/3/19 5:11 AM, Will Deacon wrote:
> > will@autoplooker:~/liburing/test$ ./io_uring_register
> > RELIMIT_MEMLOCK: 67108864 (67108864)
> > [ 35.477875] Unable to handle kernel NULL pointer d
On Wed, Apr 03, 2019 at 09:39:52AM -0600, Jens Axboe wrote:
> On 4/3/19 9:19 AM, Will Deacon wrote:
> > On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
> >> On 4/3/19 5:11 AM, Will Deacon wrote:
> >>> will@autoplooker:~/liburing/test$ ./io_uring_r
33 matches
Mail list logo
