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:
> > >
> > >
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:
> > >
> > >
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 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
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
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
> > >
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
> > >
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
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
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
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
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,
> > > >
> > > >
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,
> > > >
> > > >
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
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
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
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
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
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
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
> > >
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
> > >
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()
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()
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
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
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 =
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,
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,
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 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
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
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
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
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
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
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
>
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
>
- 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
>> >
- 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
>> >
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
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
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
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
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
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
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 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
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
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
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
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
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
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
> >>
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
> >>
- 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 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
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
- 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)
- 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)
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 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: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 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=126716090413065=2
>
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=126716090413065=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
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
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 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 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 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:
[...]
>
>>
- 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:
[...]
>
>>
- 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:
>> >
>> > >
- 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:
>> >
>> > >
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
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
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():
> >
> >
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():
> >
> >
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
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
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 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
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
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
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
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
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
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 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
1 - 100 of 112 matches
Mail list logo
