Hi Nick,
See below,
On Thu, Jul 27, 2017 at 03:56:10PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 27, 2017 at 06:08:16AM -0700, Paul E. McKenney wrote:
>
> > > So I think we need either switch_mm() or switch_to() to imply a full
> > > barrier for this to work, otherwise we get:
> > >
> > > C
On Thu, Jul 27, 2017 at 10:47:03PM +0800, Boqun Feng wrote:
> On Thu, Jul 27, 2017 at 07:36:58AM -0700, Paul E. McKenney wrote:
> > > >
> > > > The reporting of the quiescent state will acquire the leaf rcu_node
> > > > structure's lock, with an smp_mb__after_unlock_lock(), which will
> > > > one
On Thu, Jul 27, 2017 at 12:24:22PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 26, 2017 at 11:30:32AM -0700, Paul E. McKenney wrote:
> > The patch I posted reverts to synchronize_sched() in kernels booted with
> > rcupdate.rcu_normal=1. ;-)
>
> So boot parameters are no solution and are only sligh
On Thu, Jul 27, 2017 at 07:36:58AM -0700, Paul E. McKenney wrote:
> > >
> > > The reporting of the quiescent state will acquire the leaf rcu_node
> > > structure's lock, with an smp_mb__after_unlock_lock(), which will
> > > one way or another be a full memory barrier. So the reorderings
> > > can
On Thu, Jul 27, 2017 at 04:36:24PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 27, 2017 at 07:32:05AM -0700, Paul E. McKenney wrote:
> > > as per your proposed patch, will spray IPIs to all CPUs and at high
> > > rates.
> >
> > OK, I have updated my patch to do throttling.
>
> But not respect cpus
On Thu, Jul 27, 2017 at 12:39:36PM +, Mathieu Desnoyers wrote:
> - On Jul 26, 2017, at 9:45 PM, Paul E. McKenney
> paul...@linux.vnet.ibm.com wrote:
>
> > On Wed, Jul 26, 2017 at 02:11:46PM -0700, Paul E. McKenney wrote:
> >> On Wed, Jul 26, 2017 at 08:37:23PM +, Mathieu Desnoyers wro
On Thu, Jul 27, 2017 at 07:36:58AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 27, 2017 at 10:29:55PM +0800, Boqun Feng wrote:
> > On Thu, Jul 27, 2017 at 07:16:33AM -0700, Paul E. McKenney wrote:
> > > On Thu, Jul 27, 2017 at 09:55:51PM +0800, Boqun Feng wrote:
> > > > Hi Paul,
> > > >
> > > > I
On Thu, Jul 27, 2017 at 10:29:55PM +0800, Boqun Feng wrote:
> On Thu, Jul 27, 2017 at 07:16:33AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 27, 2017 at 09:55:51PM +0800, Boqun Feng wrote:
> > > Hi Paul,
> > >
> > > I have a side question out of curiosity:
> > >
> > > How does synchronize_sche
On Thu, Jul 27, 2017 at 07:32:05AM -0700, Paul E. McKenney wrote:
> > as per your proposed patch, will spray IPIs to all CPUs and at high
> > rates.
>
> OK, I have updated my patch to do throttling.
But not respect cpusets. Which is the other important point.
The scheduler based IPIs are limited
On Thu, Jul 27, 2017 at 03:37:29PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 27, 2017 at 05:56:59AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 27, 2017 at 12:14:26PM +0200, Peter Zijlstra wrote:
> > > On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
> > > > This horse is alrea
On Thu, Jul 27, 2017 at 03:49:08PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 27, 2017 at 06:08:16AM -0700, Paul E. McKenney wrote:
>
> > > No. Its called wakeup latency :-) Your SCHED_OTHER task will not get to
> > > insta-run all the time. If there are other tasks already running, we'll
> > > no
On Thu, Jul 27, 2017 at 07:16:33AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 27, 2017 at 09:55:51PM +0800, Boqun Feng wrote:
> > Hi Paul,
> >
> > I have a side question out of curiosity:
> >
> > How does synchronize_sched() work properly for sys_membarrier()?
> >
> > sys_membarrier() requires
On Thu, Jul 27, 2017 at 09:55:51PM +0800, Boqun Feng wrote:
> Hi Paul,
>
> I have a side question out of curiosity:
>
> How does synchronize_sched() work properly for sys_membarrier()?
>
> sys_membarrier() requires every other CPU does a smp_mb() before it
> returns, and I know synchronize_sched
On Thu, Jul 27, 2017 at 06:08:16AM -0700, Paul E. McKenney wrote:
> > So I think we need either switch_mm() or switch_to() to imply a full
> > barrier for this to work, otherwise we get:
> >
> > CPU0 CPU1
> >
> >
> > lock rq->lock
> > mb
> >
> > rq->curr =
Hi Paul,
I have a side question out of curiosity:
How does synchronize_sched() work properly for sys_membarrier()?
sys_membarrier() requires every other CPU does a smp_mb() before it
returns, and I know synchronize_sched() will wait until all CPUs running
a kernel thread do a context-switch, whi
On Thu, Jul 27, 2017 at 06:08:16AM -0700, Paul E. McKenney wrote:
> > No. Its called wakeup latency :-) Your SCHED_OTHER task will not get to
> > insta-run all the time. If there are other tasks already running, we'll
> > not IPI unless it should preempt.
> >
> > If its idle, nobody cares..
>
>
On Thu, Jul 27, 2017 at 05:56:59AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 27, 2017 at 12:14:26PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
> > > This horse is already out, so trying to shut the gate won't be effective.
> >
> > So I'm n
On Thu, Jul 27, 2017 at 10:53:12AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu Desnoyers wrote:
>
> > Another alternative for a MEMBARRIER_CMD_SHARED_EXPEDITED would be
> > rate-limiting
> > per thread. For instance, we could add a new "ulimit" that would boun
On Thu, Jul 27, 2017 at 10:30:03AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 26, 2017 at 08:41:10AM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 26, 2017 at 09:41:28AM +0200, Peter Zijlstra wrote:
> > > On Tue, Jul 25, 2017 at 04:59:36PM -0700, Paul E. McKenney wrote:
>
> > > Sure, but SCHED_OT
On Thu, Jul 27, 2017 at 12:14:26PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
> > This horse is already out, so trying to shut the gate won't be effective.
>
> So I'm not convinced it is. The mprotect() hack isn't portable as we've
> establishe
- On Jul 26, 2017, at 9:45 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Wed, Jul 26, 2017 at 02:11:46PM -0700, Paul E. McKenney wrote:
>> On Wed, Jul 26, 2017 at 08:37:23PM +, Mathieu Desnoyers wrote:
>> > - On Jul 26, 2017, at 2:30 PM, Paul E. McKenney
>> > paul...@li
On Wed, Jul 26, 2017 at 11:30:32AM -0700, Paul E. McKenney wrote:
> The patch I posted reverts to synchronize_sched() in kernels booted with
> rcupdate.rcu_normal=1. ;-)
So boot parameters are no solution and are only slightly better than
compile time switches.
What if you have a machine that ru
On Thu, Jul 27, 2017 at 10:53:12AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu Desnoyers wrote:
>
> > Another alternative for a MEMBARRIER_CMD_SHARED_EXPEDITED would be
> > rate-limiting
> > per thread. For instance, we could add a new "ulimit" that would boun
On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
> This horse is already out, so trying to shut the gate won't be effective.
So I'm not convinced it is. The mprotect() hack isn't portable as we've
established and on x86 where it does work, it doesn't (much) perturb
tasks not relat
On Thu, Jul 27, 2017 at 10:53:12AM +0200, Peter Zijlstra wrote:
> Another crazy idea is using madvise() for this. The new MADV_MEMBAR
> could revoke PROT_WRITE and PROT_READ for all extant PTEs. Then the
> tasks attempting access will fault and the fault handler can figure out
> if it still needs
On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu Desnoyers wrote:
> Another alternative for a MEMBARRIER_CMD_SHARED_EXPEDITED would be
> rate-limiting
> per thread. For instance, we could add a new "ulimit" that would bound the
> number of expedited membarrier per thread that can be done per mil
On Wed, Jul 26, 2017 at 08:41:10AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 26, 2017 at 09:41:28AM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 25, 2017 at 04:59:36PM -0700, Paul E. McKenney wrote:
> > Sure, but SCHED_OTHER auto throttles in that if there's anything else to
> > run, you get to
On Wed, Jul 26, 2017 at 02:11:46PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 26, 2017 at 08:37:23PM +, Mathieu Desnoyers wrote:
> > - On Jul 26, 2017, at 2:30 PM, Paul E. McKenney
> > paul...@linux.vnet.ibm.com wrote:
> >
> > > On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu Desnoyer
On Wed, Jul 26, 2017 at 08:37:23PM +, Mathieu Desnoyers wrote:
> - On Jul 26, 2017, at 2:30 PM, Paul E. McKenney
> paul...@linux.vnet.ibm.com wrote:
>
> > On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu Desnoyers wrote:
> >> - On Jul 26, 2017, at 11:42 AM, Paul E. McKenney
> >> pau
- On Jul 26, 2017, at 2:30 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu Desnoyers wrote:
>> - On Jul 26, 2017, at 11:42 AM, Paul E. McKenney
>> paul...@linux.vnet.ibm.com
>> wrote:
>>
>> > On Wed, Jul 26, 2017 at 09:46:56AM +
On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu Desnoyers wrote:
> - On Jul 26, 2017, at 11:42 AM, Paul E. McKenney
> paul...@linux.vnet.ibm.com wrote:
>
> > On Wed, Jul 26, 2017 at 09:46:56AM +0200, Peter Zijlstra wrote:
> >> On Tue, Jul 25, 2017 at 10:50:13PM +, Mathieu Desnoyers wrot
- On Jul 26, 2017, at 11:42 AM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Wed, Jul 26, 2017 at 09:46:56AM +0200, Peter Zijlstra wrote:
>> On Tue, Jul 25, 2017 at 10:50:13PM +, Mathieu Desnoyers wrote:
>> > This would implement a MEMBARRIER_CMD_PRIVATE_EXPEDITED (or such) fla
On Wed, Jul 26, 2017 at 10:36:46AM +0100, Will Deacon wrote:
> On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote:
> > Some architectures are less precise than others in tracking which
> > CPUs are running a given process due to ASIDs, though this is
> > thought to be a non-problem:
>
On Wed, Jul 26, 2017 at 09:46:56AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 10:50:13PM +, Mathieu Desnoyers wrote:
> > This would implement a MEMBARRIER_CMD_PRIVATE_EXPEDITED (or such) flag
> > for expedited process-local effect. This differs from the "SHARED" flag,
> > since the
On Wed, Jul 26, 2017 at 09:41:28AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 04:59:36PM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 25, 2017 at 11:55:10PM +0200, Peter Zijlstra wrote:
>
> > > People always do crazy stuff, but what surprised me is that such s patch
> > > got merged
On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote:
> Some architectures are less precise than others in tracking which
> CPUs are running a given process due to ASIDs, though this is
> thought to be a non-problem:
>
> https://marc.info/?l=linux-arch&m=126716090413065&w=2
>
On Tue, Jul 25, 2017 at 10:50:13PM +, Mathieu Desnoyers wrote:
> This would implement a MEMBARRIER_CMD_PRIVATE_EXPEDITED (or such) flag
> for expedited process-local effect. This differs from the "SHARED" flag,
> since the SHARED flag affects threads accessing memory mappings shared
> across pr
On Tue, Jul 25, 2017 at 04:59:36PM -0700, Paul E. McKenney wrote:
> On Tue, Jul 25, 2017 at 11:55:10PM +0200, Peter Zijlstra wrote:
> > People always do crazy stuff, but what surprised me is that such s patch
> > got merged in urcu even though its known broken for a number of
> > architectures.
>
On Tue, Jul 25, 2017 at 10:50:13PM +, Mathieu Desnoyers wrote:
> - On Jul 25, 2017, at 5:55 PM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote:
> >> On Tue, Jul 25, 2017 at 10:24:51PM +0200, Peter Zijlstra wrote:
> >> > On
On Tue, Jul 25, 2017 at 11:55:10PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 25, 2017 at 10:24:51PM +0200, Peter Zijlstra wrote:
> > > On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
> > >
> > > > There are a
- On Jul 25, 2017, at 5:55 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote:
>> On Tue, Jul 25, 2017 at 10:24:51PM +0200, Peter Zijlstra wrote:
>> > On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
[...]
>
>> Bu
- On Jul 25, 2017, at 5:55 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote:
>> On Tue, Jul 25, 2017 at 10:24:51PM +0200, Peter Zijlstra wrote:
>> > On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
>> >
>> > > T
On Tue, Jul 25, 2017 at 02:19:26PM -0700, Paul E. McKenney wrote:
> On Tue, Jul 25, 2017 at 10:24:51PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
> >
> > > There are a lot of variations, to be sure. For whatever it is worth,
> > > the origin
On Tue, Jul 25, 2017 at 10:24:51PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
>
> > There are a lot of variations, to be sure. For whatever it is worth,
> > the original patch that started this uses mprotect():
> >
> > https://github.com/msul
On Tue, Jul 25, 2017 at 12:36:12PM -0700, Paul E. McKenney wrote:
> There are a lot of variations, to be sure. For whatever it is worth,
> the original patch that started this uses mprotect():
>
> https://github.com/msullivan/userspace-rcu/commit/04656b468d418efbc5d934ab07954eb8395a7ab0
FWIW th
On Tue, Jul 25, 2017 at 08:53:20PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 10:17:01AM -0700, Paul E. McKenney wrote:
>
> > > munmap() TLB invalidate is limited to those CPUs that actually ran
> > > threads of their process, while this is machine wide.
> >
> > Or those CPUs running
On Tue, Jul 25, 2017 at 10:17:01AM -0700, Paul E. McKenney wrote:
> > munmap() TLB invalidate is limited to those CPUs that actually ran
> > threads of their process, while this is machine wide.
>
> Or those CPUs running threads of any process mapping the underlying file
> or whatever.
That does
On Tue, Jul 25, 2017 at 06:59:57PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 09:49:00AM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 25, 2017 at 06:33:18PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jul 24, 2017 at 02:58:16PM -0700, Paul E. McKenney wrote:
> > > > The sys_membarrier(
On Tue, Jul 25, 2017 at 09:49:00AM -0700, Paul E. McKenney wrote:
> On Tue, Jul 25, 2017 at 06:33:18PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 24, 2017 at 02:58:16PM -0700, Paul E. McKenney wrote:
> > > The sys_membarrier() system call has proven too slow for some use
> > > cases, which has pr
On Tue, Jul 25, 2017 at 06:33:18PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 24, 2017 at 02:58:16PM -0700, Paul E. McKenney wrote:
> > The sys_membarrier() system call has proven too slow for some use
> > cases, which has prompted users to instead rely on TLB shootdown.
> > Although TLB shootdown
On Tue, Jul 25, 2017 at 01:21:08PM +, Mathieu Desnoyers wrote:
> - On Jul 24, 2017, at 5:58 PM, Paul E. McKenney
> paul...@linux.vnet.ibm.com wrote:
>
> > The sys_membarrier() system call has proven too slow for some use
> > cases, which has prompted users to instead rely on TLB shootdown
On Mon, Jul 24, 2017 at 02:58:16PM -0700, Paul E. McKenney wrote:
> The sys_membarrier() system call has proven too slow for some use
> cases, which has prompted users to instead rely on TLB shootdown.
> Although TLB shootdown is much faster, it has the slight disadvantage
> of not working at all o
On Tue, Jul 25, 2017 at 12:27:01PM +0800, Boqun Feng wrote:
> On Mon, Jul 24, 2017 at 02:58:16PM -0700, Paul E. McKenney wrote:
> > The sys_membarrier() system call has proven too slow for some use
> > cases, which has prompted users to instead rely on TLB shootdown.
> > Although TLB shootdown is m
- On Jul 24, 2017, at 5:58 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> The sys_membarrier() system call has proven too slow for some use
> cases, which has prompted users to instead rely on TLB shootdown.
> Although TLB shootdown is much faster, it has the slight disadvantage
> o
On Mon, Jul 24, 2017 at 02:58:16PM -0700, Paul E. McKenney wrote:
> The sys_membarrier() system call has proven too slow for some use
> cases, which has prompted users to instead rely on TLB shootdown.
> Although TLB shootdown is much faster, it has the slight disadvantage
> of not working at all o
The sys_membarrier() system call has proven too slow for some use
cases, which has prompted users to instead rely on TLB shootdown.
Although TLB shootdown is much faster, it has the slight disadvantage
of not working at all on arm and arm64. This commit therefore adds
an expedited option to the sy
56 matches
Mail list logo
