On Tue, May 28, 2019 at 03:00:07PM -0400, Joel Fernandes wrote:
> On Tue, May 28, 2019 at 05:24:47AM -0700, Paul E. McKenney wrote:
> > On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
> > > On Sat, May 25, 2019 at 08:50:35AM -0700, Paul E. McKenney wrote:
>
On Fri, Jan 28, 2022 at 04:11:57PM +, Mark Rutland wrote:
> On Fri, Jan 28, 2022 at 05:08:48PM +0100, Sven Schnelle wrote:
> > Hi Mark,
> >
> > Mark Rutland writes:
> >
> > > On arm64 I bisected this down to:
> > >
> > > 7a30871b6a27de1a ("rcu-tasks: Introduce ->percpu_enqueue_shift for
>
On Fri, Jan 28, 2022 at 08:15:47AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 28, 2022 at 04:11:57PM +, Mark Rutland wrote:
> > On Fri, Jan 28, 2022 at 05:08:48PM +0100, Sven Schnelle wrote:
> > > Hi Mark,
> > >
> > > Mark Rutland writes:
> > &
On Mon, Feb 07, 2022 at 05:44:47PM +0100, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On the POWER8 server IBM S822LC running Ubuntu 21.10, building Linux
> 5.17-rc2+ with rcutorture tests
>
> $ tools/testing/selftests/rcutorture/bin/torture.sh --duration 10
>
> the built init
>
> $ f
On Mon, Feb 07, 2022 at 05:53:05PM +0100, Paul Menzel wrote:
> Dear Sebastian, dear Paul,
>
>
> In commit a6fda6dab9 (rcutorture: Tweak kvm options)
> `tools/testing/selftests/rcutorture/configs/rcu/CFcommon` was extended by
> the three selections below:
>
> CONFIG_HYPERVISOR_GUEST=y
> C
CONFIG_ARCH_WEAK_RELACQ, has PPC select it,
and bases the definition of smp_mb__after_unlock_lock() on this new
CONFIG_ARCH_WEAK_RELACQ Kconfig option.
Reported-by: Ingo Molnar
Signed-off-by: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Boqun Feng
Cc: Benjamin Herrenschmidt
Cc: Paul
On Thu, Apr 13, 2017 at 11:21:53AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 12, 2017 at 10:39:47AM -0700, Paul E. McKenney wrote:
>
> > CONFIG_ARCH_WEAK_RELACQ Kconfig option.
>
> Naming in the changelog and patch don't ma
On Thu, Apr 13, 2017 at 11:24:18AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 12, 2017 at 10:39:47AM -0700, Paul E. McKenney wrote:
> > The definition of smp_mb__after_unlock_lock() is currently smp_mb()
> > for CONFIG_PPC and a no-op otherwise. It would be better to instead
On Thu, Apr 13, 2017 at 06:37:57PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 09:26:51AM -0700, Paul E. McKenney wrote:
>
> > ARCH_WEAK_RELEASE_ACQUIRE actually works both ways.
> >
> > To see this, imagine some strange alternate universe in which the Power
&g
ARCH_WEAK_RELEASE_ACQUIRE, has PPC select it,
and bases the definition of smp_mb__after_unlock_lock() on this new
ARCH_WEAK_RELEASE_ACQUIRE Kconfig option.
Reported-by: Ingo Molnar
Signed-off-by: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Boqun Feng
Cc: Benjamin Herrenschmidt
Cc
On Wed, Apr 19, 2017 at 11:38:22PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
>
> > On Thu, Apr 13, 2017 at 06:37:57PM +0200, Peter Zijlstra wrote:
> >> On Thu, Apr 13, 2017 at 09:26:51AM -0700, Paul E. McKenney wrote:
> >>
> >>
ARCH_WEAK_RELEASE_ACQUIRE, has PPC select it,
and bases the definition of smp_mb__after_unlock_lock() on this new
ARCH_WEAK_RELEASE_ACQUIRE Kconfig option.
Reported-by: Ingo Molnar
Signed-off-by: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Boqun Feng
Cc: Benjamin Herrenschmidt
Cc
On Thu, Apr 20, 2017 at 01:40:13PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
>
> > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> > index f2b3bd6c6bc2..0400e211aa44 100644
> > --- a/include/linux/srcutree.h
> > +++
On Thu, Apr 20, 2017 at 03:36:47PM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> [Also reported by Michael elsewhere]
>
> After merging the rcu tree, today's linux-next build (powerpc
> pseries_le_defconfig) failed like this:
>
> arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages:
> arc
On Thu, Apr 20, 2017 at 05:28:32PM +0200, Paolo Bonzini wrote:
>
>
> On 20/04/2017 05:40, Michael Ellerman wrote:
> > "Paul E. McKenney" writes:
> >
> >> diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> >> index f2b3bd6c6
On Fri, Apr 21, 2017 at 11:42:01AM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > On Thu, Apr 20, 2017 at 05:28:32PM +0200, Paolo Bonzini wrote:
> >> On 20/04/2017 05:40, Michael Ellerman wrote:
> >> > "Paul E. McKenney" writes
On Fri, Apr 21, 2017 at 09:27:59AM +0200, Paolo Bonzini wrote:
>
>
> On 21/04/2017 06:17, Paul E. McKenney wrote:
> >> Thanks, this looks perfect to me, and if you're happy to put it on top
> >> of your tree that would limit the breakage to a smaller history win
There is no agreed-upon definition of spin_unlock_wait()'s semantics,
and it appears that all callers could do just as well with a lock/unlock
pair. This commit therefore removes the underlying arch-specific
arch_spin_unlock_wait().
Signed-off-by: Paul E. McKenney
Cc: Benjamin Herrenschmid
On Fri, Jun 30, 2017 at 05:28:02PM +1000, Nicholas Piggin wrote:
> On Fri, 30 Jun 2017 10:52:18 +0530
> Abdul Haleem wrote:
>
> > On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote:
> > > On Thu, 29 Jun 2017 20:23:05 +1000
> > > Nicholas Piggin wrote:
> > >
> > > > On Thu, 29 Jun 2017 19:
On Tue, Jul 04, 2017 at 07:44:58PM +0530, Abdul Haleem wrote:
> On Fri, 2017-06-30 at 17:28 +1000, Nicholas Piggin wrote:
> > On Fri, 30 Jun 2017 10:52:18 +0530
> > Abdul Haleem wrote:
> >
> > > On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote:
> > > > On Thu, 29 Jun 2017 20:23:05 +1000
>
On Sun, Jul 02, 2017 at 11:58:07AM +0800, Boqun Feng wrote:
> On Thu, Jun 29, 2017 at 05:01:29PM -0700, Paul E. McKenney wrote:
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock/un
anges since v4:
> - Move powerpc hook from sched_in() to switch_mm(), based on feedback
> from Nicholas Piggin.
>
> Signed-off-by: Mathieu Desnoyers
> CC: Peter Zijlstra
> CC: Paul E. McKenney
> CC: Boqun Feng
> CC: Andrew Hunter
> CC: Maged Michael
> CC: gro...@goo
for membarrier_private_expedited field access in
membarrier_private_expedited. Matches WRITE_ONCE() performed in
process registration.
Changes since v4:
- Move powerpc hook from sched_in() to switch_mm(), based on feedback
from Nicholas Piggin.
Signed-off-by: Mathieu Desnoyers
CC: Peter Zijlstra
CC: Paul E. McKen
Thanx, Paul
> CC: Peter Zijlstra
> CC: Paul E. McKenney
> CC: Boqun Feng
> CC: Andrew Hunter
> CC: Maged Michael
> CC: gro...@google.com
> CC: Avi Kivity
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Michael Ellerman
> CC: Dave Watson
hooks.
Reported-by: Nicholas Piggin
Signed-off-by: Mathieu Desnoyers
CC: Peter Zijlstra
CC: Paul E. McKenney
CC: Boqun Feng
CC: Andrew Hunter
CC: Maged Michael
CC: gro...@google.com
CC: Avi Kivity
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Dave Watson
CC: Alan
for membarrier_private_expedited field access in
membarrier_private_expedited. Matches WRITE_ONCE() performed in
process registration.
Changes since v4:
- Move powerpc hook from sched_in() to switch_mm(), based on feedback
from Nicholas Piggin.
Signed-off-by: Mathieu Desnoyers
CC: Peter Zijlstra
CC: Paul E. McKen
ivate
expedited membarrier commands to succeed. membarrier_arch_switch_mm()
now tests for the MEMBARRIER_STATE_SWITCH_MM flag.
Changes since v1:
- Remove membarrier thread flag on powerpc (now unused).
Reported-by: Peter Zijlstra
Signed-off-by: Mathieu Desnoyers
CC: Paul E. McKenney
CC: Boqun F
On Thu, Dec 08, 2016 at 11:54:15AM +0530, Sachin Sant wrote:
> RCU Torture test on powerpc fails during its run against latest mainline
> (4.9.0-rc8) tree.
>
> 07:58:25 BUG: rcutorture tests failed !
> 07:58:25 21:31:00 ERROR| child process failed
> 07:58:25 21:31:00 INFO | ERROR rc
On Fri, Dec 09, 2016 at 04:27:42PM +0530, Sachin Sant wrote:
> > But I am not seeing this as a failure. The last status print from the
> > log you attached is as follows:
> >
> > 07:58:25 [ 2778.876118] rcu-torture: rtc: (null) ver: 24968 tfle:
> > 0 rta: 24968 rtaf: 0 rtf: 24959 rtmbe
On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote:
> On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote:
> > * Paul E. McKenney wrote:
[ . . . ]
> > > + */
> > > +#ifdef CONFIG_PPC
> > > +#define smp_mb__after_unlock_lock() smp_mb
On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 357b32aaea48..5fdfe874229e 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include
On Sun, Jan 15, 2017 at 08:57:11AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney wrote:
> > >
> > > > diff --git a/include/lin
On Sun, Jan 15, 2017 at 10:40:58AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > > [sounds of rummaging around in the Git tree]
> > >
> > > I found this commit of yours from ancient history (more than a year ago!):
> > >
> >
On Mon, Jan 23, 2017 at 07:12:03PM +1100, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
>
> > On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote:
> >> On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote:
&
On Fri, Feb 03, 2017 at 02:37:48PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 03, 2017 at 01:59:34PM +0100, Mike Galbraith wrote:
> > On Fri, 2017-02-03 at 09:53 +0100, Peter Zijlstra wrote:
> > > On Fri, Feb 03, 2017 at 10:03:14AM +0530, Sachin Sant wrote:
> >
> > > > I ran few cycles of cpu hot(
On Fri, Feb 03, 2017 at 07:44:57AM -0800, Paul E. McKenney wrote:
> On Fri, Feb 03, 2017 at 02:37:48PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 03, 2017 at 01:59:34PM +0100, Mike Galbraith wrote:
> > > On Fri, 2017-02-03 at 09:53 +0100, Peter Zijlstra wrote:
> > > &
On Mon, Feb 06, 2017 at 11:53:10AM +0530, Sachin Sant wrote:
>
> >>> I've seen it on tip. It looks like hot unplug goes really slow when
> >>> there's running tasks on the CPU being taken down.
> >>>
> >>> What I did was something like:
> >>>
> >>> taskset -p $((1<<1)) $$
> >>> for ((i=0; i<20
On Mon, Feb 06, 2017 at 07:10:48AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 06, 2017 at 11:53:10AM +0530, Sachin Sant wrote:
> >
> > >>> I've seen it on tip. It looks like hot unplug goes really slow when
> > >>> there's running tasks on the
nel code.
Signed-off-by: Yury Norov
Signed-off-by: Paul E. McKenney
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index fd996cdf1833..448f20f27396 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -74,6 +74,7 @@ static inline void synchronize_rcu_
On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote:
> kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast IPI.
> If CPU is in extended quiescent state (idle task or nohz_full userspace), this
> work may be done at the exit of this state. Delaying synchronization helps t
On Sun, Mar 25, 2018 at 11:11:54PM +0300, Yury Norov wrote:
> On Sun, Mar 25, 2018 at 12:23:28PM -0700, Paul E. McKenney wrote:
> > On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote:
> > > kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast
> >
On Wed, Mar 28, 2018 at 05:41:40PM +0300, Yury Norov wrote:
> On Wed, Mar 28, 2018 at 06:56:17AM -0700, Paul E. McKenney wrote:
> > On Wed, Mar 28, 2018 at 04:36:05PM +0300, Yury Norov wrote:
> > > On Mon, Mar 26, 2018 at 05:45:55AM -0700, Paul E. McKenney wrote:
> > > &
On Wed, Mar 28, 2018 at 04:36:05PM +0300, Yury Norov wrote:
> On Mon, Mar 26, 2018 at 05:45:55AM -0700, Paul E. McKenney wrote:
> > On Sun, Mar 25, 2018 at 11:11:54PM +0300, Yury Norov wrote:
> > > On Sun, Mar 25, 2018 at 12:23:28PM -0700, Paul E. McKenney wrote:
> > > &
On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote:
> On Tue, Mar 27, 2018 at 11:21:17AM +0100, Will Deacon wrote:
> > On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote:
> > > kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast
> > > IPI.
> > > If CPU is in ex
On Wed, May 23, 2018 at 04:14:39PM -0400, Mathieu Desnoyers wrote:
> - On May 20, 2018, at 10:08 AM, Boqun Feng boqun.f...@gmail.com wrote:
>
> > On Fri, May 18, 2018 at 02:17:17PM -0400, Mathieu Desnoyers wrote:
> >> - On May 17, 2018, at 7:50 PM, Boqun Feng boqun.f...@gmail.com wrote:
>
On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
> On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
> > The option "-soundhw pcspk" gives me a error on PPC as follow:
> >
> > qemu-system-ppc64: ISA bus not available for pcspk
> >
> > , which means this option doesn't work
On Wed, May 18, 2016 at 09:25:17PM -0700, Josh Triplett wrote:
> On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote:
> > I spend some time to make tools/testing/selftest/rcutorture run on PPC,
> > here are some documention and fixes made while I was trying.
> >
> > The scripts are able to
On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
> On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
> > On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
> > > On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
> > > &
On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
> On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
> > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
> > > On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
> >
On Thu, May 19, 2016 at 01:24:12PM -0700, Josh Triplett wrote:
> On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote:
> > On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
> > > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
> >
On Tue, Jul 25, 2017 at 10:26:54PM +1000, Nicholas Piggin wrote:
> On Tue, 25 Jul 2017 19:32:10 +0800
> Jonathan Cameron wrote:
>
> > Hi All,
> >
> > We observed a regression on our d05 boards (but curiously not
> > the fairly similar but single socket / smaller core count
> > d03), initially se
On Tue, Jul 25, 2017 at 10:42:45PM +0800, Jonathan Cameron wrote:
> On Tue, 25 Jul 2017 06:46:26 -0700
> "Paul E. McKenney" wrote:
>
> > On Tue, Jul 25, 2017 at 10:26:54PM +1000, Nicholas Piggin wrote:
> > > On Tue, 25 Jul 2017 19:32:10 +0800
> > > J
On Wed, Jul 26, 2017 at 12:52:07AM +0800, Jonathan Cameron wrote:
> On Tue, 25 Jul 2017 08:12:45 -0700
> "Paul E. McKenney" wrote:
>
> > On Tue, Jul 25, 2017 at 10:42:45PM +0800, Jonathan Cameron wrote:
> > > On Tue, 25 Jul 2017 06:46:26 -0700
> > > &qu
On Tue, Jul 25, 2017 at 02:10:29PM -0700, David Miller wrote:
> From: Jonathan Cameron
> Date: Wed, 26 Jul 2017 00:52:07 +0800
>
> > On Tue, 25 Jul 2017 08:12:45 -0700
> > "Paul E. McKenney" wrote:
> >
> >> On Tue, Jul 25, 2017 at 10:42:45PM +0800,
On Tue, Jul 25, 2017 at 09:02:33PM -0700, David Miller wrote:
> From: "Paul E. McKenney"
> Date: Tue, 25 Jul 2017 20:55:45 -0700
>
> > On Tue, Jul 25, 2017 at 02:10:29PM -0700, David Miller wrote:
> >> Just to report, turning softlockup back on fixes
On Wed, Jul 26, 2017 at 01:28:01PM +0100, Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 10:32:32 +0100
> Jonathan Cameron wrote:
>
> > On Wed, 26 Jul 2017 09:16:23 +0100
> > Jonathan Cameron wrote:
> >
> > > On Tue, 25 Jul 2017 21:12:17 -
On Wed, Jul 26, 2017 at 04:33:40PM +0100, Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 15:23:15 +0100
> Jonathan Cameron wrote:
>
> > On Wed, 26 Jul 2017 07:14:17 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Wed, Jul 26, 2017 at 01:28:01PM +
On Wed, Jul 26, 2017 at 09:54:32AM -0700, David Miller wrote:
> From: "Paul E. McKenney"
> Date: Wed, 26 Jul 2017 08:49:00 -0700
>
> > On Wed, Jul 26, 2017 at 04:33:40PM +0100, Jonathan Cameron wrote:
> >> Didn't leave it long enough. Still bad on 4.10-r
On Wed, Jul 26, 2017 at 10:50:13AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 26, 2017 at 09:54:32AM -0700, David Miller wrote:
> > From: "Paul E. McKenney"
> > Date: Wed, 26 Jul 2017 08:49:00 -0700
> >
> > > On Wed, Jul 26, 2017 at 04:33:40PM +0100, Jon
On Wed, Jul 26, 2017 at 03:45:40PM -0700, David Miller wrote:
> From: "Paul E. McKenney"
> Date: Wed, 26 Jul 2017 15:36:58 -0700
>
> > And without CONFIG_SOFTLOCKUP_DETECTOR, I see five runs of 24 with RCU
> > CPU stall warnings. So it seems likely that CONFIG_SO
On Wed, Jul 26, 2017 at 04:22:00PM -0700, David Miller wrote:
> From: "Paul E. McKenney"
> Date: Wed, 26 Jul 2017 16:15:05 -0700
>
> > On Wed, Jul 26, 2017 at 03:45:40PM -0700, David Miller wrote:
> >> Just out of curiousity, what x86 idle method is your machin
On Thu, Jul 27, 2017 at 02:34:00PM +1000, Nicholas Piggin wrote:
> On Wed, 26 Jul 2017 18:42:14 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Jul 26, 2017 at 04:22:00PM -0700, David Miller wrote:
>
> > > Indeed, that really wouldn't explain how we
On Thu, Jul 27, 2017 at 05:39:23PM +0100, Jonathan Cameron wrote:
> On Thu, 27 Jul 2017 14:49:03 +0100
> Jonathan Cameron wrote:
>
> > On Thu, 27 Jul 2017 05:49:13 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Thu, Jul 27, 2017 at 02:34:00PM
n.
>
> This patch then removes the lockless swait_active() check in swake_up()
> and swake_up_all().
>
> Reported-by: Steven Rostedt
> Signed-off-by: Boqun Feng
Even though Jonathan's testing indicates that it didn't fix this
particular problem:
Acked-by: Pau
On Fri, Jul 28, 2017 at 07:55:30AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 28, 2017 at 08:54:16PM +0800, Boqun Feng wrote:
> > Hi Jonathan,
> >
> > FWIW, there is wakeup-missing issue in swake_up() and swake_up_all():
> >
> > https://marc.info/
On Fri, Jul 28, 2017 at 06:27:05PM +0100, Jonathan Cameron wrote:
> On Fri, 28 Jul 2017 09:55:29 -0700
> "Paul E. McKenney" wrote:
>
> > On Fri, Jul 28, 2017 at 02:24:03PM +0100, Jonathan Cameron wrote:
> > > On Fri, 28 Jul 2017 08:44:11 +
On Fri, Jul 28, 2017 at 11:41:29AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 28, 2017 at 07:55:30AM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 28, 2017 at 08:54:16PM +0800, Boqun Feng wrote:
[ . . . ]
> > Even though Jonathan's testing indicates that it didn'
On Sun, Jul 30, 2017 at 09:37:47PM +0800, Boqun Feng wrote:
> On Fri, Jul 28, 2017 at 12:09:56PM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 28, 2017 at 11:41:29AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jul 28, 2017 at 07:55:30AM -0700, Paul E. McKenney wrote:
> >
On Mon, Jul 31, 2017 at 12:08:47PM +0100, Jonathan Cameron wrote:
> On Fri, 28 Jul 2017 12:03:50 -0700
> "Paul E. McKenney" wrote:
>
> > On Fri, Jul 28, 2017 at 06:27:05PM +0100, Jonathan Cameron wrote:
> > > On Fri, 28 Jul 2017 09:55:29 -0700
> > > &qu
On Mon, Jul 31, 2017 at 04:27:57PM +0100, Jonathan Cameron wrote:
> On Mon, 31 Jul 2017 08:04:11 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Jul 31, 2017 at 12:08:47PM +0100, Jonathan Cameron wrote:
> > > On Fri, 28 Jul 2017 12:03:50 -0700
> > > &qu
On Wed, Aug 02, 2017 at 05:25:55PM +0100, Jonathan Cameron wrote:
> On Tue, 1 Aug 2017 11:46:46 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Jul 31, 2017 at 04:27:57PM +0100, Jonathan Cameron wrote:
> > > On Mon, 31 Jul 2017 08:04:11 -0700
> > > &qu
On Wed, Aug 16, 2017 at 10:43:52PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> ...
> >
> > commit 33103e7b1f89ef432dfe3337d2a6932cdf5c1312
> > Author: Paul E. McKenney
> > Date: Mon Aug 14 08:54:39 2017 -0700
> >
> > E
On Wed, Aug 16, 2017 at 05:56:17AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 16, 2017 at 10:43:52PM +1000, Michael Ellerman wrote:
> > "Paul E. McKenney" writes:
> > ...
> > >
> > > commit 33103e7b1f89ef432dfe3337d2a6932cdf5c1312
> > > Auth
On Sun, Aug 20, 2017 at 02:45:53PM +1000, Nicholas Piggin wrote:
> On Wed, 16 Aug 2017 09:27:31 -0700
> "Paul E. McKenney" wrote:
> > On Wed, Aug 16, 2017 at 05:56:17AM -0700, Paul E. McKenney wrote:
> >
> > Thomas, John, am I misinterpreting the timer trace
On Sun, Aug 20, 2017 at 11:00:40PM +1000, Nicholas Piggin wrote:
> On Sun, 20 Aug 2017 14:45:53 +1000
> Nicholas Piggin wrote:
>
> > On Wed, 16 Aug 2017 09:27:31 -0700
> > "Paul E. McKenney" wrote:
> > > On Wed, Aug 16, 2017 at 05:56:17AM -0700, Paul E. M
On Sun, Aug 20, 2017 at 11:35:14AM -0700, Paul E. McKenney wrote:
> On Sun, Aug 20, 2017 at 11:00:40PM +1000, Nicholas Piggin wrote:
> > On Sun, 20 Aug 2017 14:45:53 +1000
> > Nicholas Piggin wrote:
> >
> > > On Wed, 16 Aug 2017 09:27:31 -0700
> > > "P
On Mon, Aug 21, 2017 at 10:52:58AM +1000, Nicholas Piggin wrote:
> On Sun, 20 Aug 2017 14:14:29 -0700
> "Paul E. McKenney" wrote:
>
> > On Sun, Aug 20, 2017 at 11:35:14AM -0700, Paul E. McKenney wrote:
> > > On Sun, Aug 20, 2017 at 11:00:40PM +1000, Nicholas
On Mon, Aug 21, 2017 at 11:58:03AM +0530, Anshuman Khandual wrote:
> On 08/18/2017 03:34 AM, Laurent Dufour wrote:
> > This is a port on kernel 4.13 of the work done by Peter Zijlstra to
> > handle page fault without holding the mm semaphore [1].
> >
> > The idea is to try to handle user space pag
On Tue, Aug 22, 2017 at 02:21:32PM +0530, Abdul Haleem wrote:
> On Tue, 2017-08-22 at 08:49 +0100, Jonathan Cameron wrote:
> > On Mon, 21 Aug 2017 13:55:04 -0700
> > David Miller wrote:
> >
> > > From: Nicholas Piggin
> > > Date: Tue, 22 Aug 2017 00:19:28 +1000
> > >
> > > > Thanks here's an up
On Wed, Aug 23, 2017 at 04:14:24AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 23 Aug 2017 04:11:17 +1000 Stephen Rothwell
> wrote:
> >
> > This tree fails to boot on my qemu test. 2 boot logs attached.
> >
> > Paul, Nick, is this the same/similar to the other RCU/lockup bug you
> > a
On Wed, Aug 23, 2017 at 05:12:16AM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> On Tue, 22 Aug 2017 11:59:23 -0700 "Paul E. McKenney"
> wrote:
> >
> > On Wed, Aug 23, 2017 at 04:14:24AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > &g
On Tue, Aug 22, 2017 at 12:32:31PM -0700, Paul E. McKenney wrote:
> On Wed, Aug 23, 2017 at 05:12:16AM +1000, Stephen Rothwell wrote:
> > Hi Paul,
> >
> > On Tue, 22 Aug 2017 11:59:23 -0700 "Paul E. McKenney"
> > wrote:
> > >
> > > On
On Tue, Aug 22, 2017 at 08:26:37AM -0700, Paul E. McKenney wrote:
> On Tue, Aug 22, 2017 at 02:21:32PM +0530, Abdul Haleem wrote:
> > On Tue, 2017-08-22 at 08:49 +0100, Jonathan Cameron wrote:
[ . . . ]
> > No more RCU stalls on PowerPC, system is clean when idle or with som
On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > Since SLOB was removed, it is not necessary to use call_rcu
> > when the callback only performs kmem_cache_free. Use
> > kfree_rcu() directly.
> >
> > The changes were done
On Wed, Jun 12, 2024 at 04:52:57PM -0600, Jens Axboe wrote:
> On 6/12/24 4:37 PM, Paul E. McKenney wrote:
> > [PATCH 09/14] block: replace call_rcu by kfree_rcu for simple
> > kmem_cache_free callback
> > I don't see a kmem_cache_destroy(), but then again, I
On Thu, Jun 13, 2024 at 02:31:53AM +0200, Jason A. Donenfeld wrote:
> On Thu, Jun 13, 2024 at 01:31:57AM +0200, Jason A. Donenfeld wrote:
> > On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
On Thu, Jun 13, 2024 at 01:58:59PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > &g
On Thu, Jun 13, 2024 at 07:17:38AM -0700, Jakub Kicinski wrote:
> On Wed, 12 Jun 2024 20:38:02 -0700 Paul E. McKenney wrote:
> > o Make rcu_barrier() wait for kfree_rcu() objects. (This is
> > surprisingly complex and will wait unnecessarily in some cases.
> > Howe
On Thu, Jun 13, 2024 at 04:11:52PM +0200, Jason A. Donenfeld wrote:
> On Thu, Jun 13, 2024 at 05:46:11AM -0700, Paul E. McKenney wrote:
> > How about a kmem_cache_destroy_rcu() that marks that specified cache
> > for destruction, and then a kmem_cache_destroy_barrier() that waits?
On Thu, Jun 13, 2024 at 07:58:17PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 10:45:59AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
>
On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 03:06:54PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 05:47:08AM -0700, Paul E. McKenney wrote:
>
On Fri, Jun 14, 2024 at 02:35:33PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 11:13:52AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 07:58:17PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 10:45:59AM -0700, Paul E. McKenney wrote:
>
On Mon, Jun 17, 2024 at 05:10:50PM +0200, Vlastimil Babka wrote:
> On 6/13/24 2:22 PM, Jason A. Donenfeld wrote:
> > On Wed, Jun 12, 2024 at 08:38:02PM -0700, Paul E. McKenney wrote:
> >> o Make the current kmem_cache_destroy() asynchronously wait for
> >>all
On Mon, Jun 17, 2024 at 07:23:36PM +0200, Vlastimil Babka wrote:
> On 6/17/24 6:12 PM, Paul E. McKenney wrote:
> > On Mon, Jun 17, 2024 at 05:10:50PM +0200, Vlastimil Babka wrote:
> >> On 6/13/24 2:22 PM, Jason A. Donenfeld wrote:
> >> > On Wed, Jun 12, 2024 at 08:3
On Tue, Jun 18, 2024 at 11:31:00AM +0200, Uladzislau Rezki wrote:
> > On 6/17/24 8:42 PM, Uladzislau Rezki wrote:
> > >> +
> > >> +s = container_of(work, struct kmem_cache, async_destroy_work);
> > >> +
> > >> +// XXX use the real kmem_cache_free_barrier() or similar thing
> > >> h
On Tue, Jun 18, 2024 at 07:21:42PM +0200, Vlastimil Babka wrote:
> On 6/18/24 6:48 PM, Paul E. McKenney wrote:
> > On Tue, Jun 18, 2024 at 11:31:00AM +0200, Uladzislau Rezki wrote:
> >> > On 6/17/24 8:42 PM, Uladzislau Rezki wrote:
> >> > >> +
> &
On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote:
> On 6/18/24 7:53 PM, Paul E. McKenney wrote:
> > On Tue, Jun 18, 2024 at 07:21:42PM +0200, Vlastimil Babka wrote:
> >> On 6/18/24 6:48 PM, Paul E. McKenney wrote:
> >> > On Tue, Jun 18, 2024 at 11:3
On Mon, Jul 15, 2024 at 10:39:38PM +0200, Vlastimil Babka wrote:
> On 6/21/24 11:32 AM, Uladzislau Rezki wrote:
> > On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote:
> > One question. Maybe it is already late but it is better to ask rather than
> > not.
> >
> > What do you think if
On Fri, May 27, 2022 at 02:49:03PM +0800, Chen Zhongjin wrote:
> Hi,
>
> On 2022/5/18 9:11, Paul E. McKenney wrote:
> > On Tue, May 17, 2022 at 11:22:04AM +0800, Chen Zhongjin wrote:
> >> On 2022/5/10 17:46, Chen Zhongjin wrote:
> >>> csdlock_debug uses early
t; can remove these calls.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Acked-by: Paul E. McKenney
We have some fun conflicts between this series and Frederic's context-tracking
series. But it looks like these can be resolved by:
1. A patch on top of Frederic's series that pr
301 - 400 of 410 matches
Mail list logo
