On Mon, Jul 31, 2017 at 11:00:19AM -0700, Dave Watson wrote:
> Hi Paul,
>
> Thanks for looking at this again!
>
> On 07/27/17 11:12 AM, Paul E. McKenney wrote:
> > Hello!
> >
> > But my main question is whether the throttling shown below is acceptable
> > for your use cases, namely only one exp
Hi Paul,
Thanks for looking at this again!
On 07/27/17 11:12 AM, Paul E. McKenney wrote:
> Hello!
>
> But my main question is whether the throttling shown below is acceptable
> for your use cases, namely only one expedited sys_membarrier() permitted
> per scheduling-clock period (1 millisecond
On 07/31/2017 11:37 AM, Peter Zijlstra wrote:
On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote:
I remembered that current->mm does not change when switching to a kernel
task, but my Kernlish is very rusty, or maybe it has changed.
kernel threads do indeed preserve the mm of the old us
On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote:
> I remembered that current->mm does not change when switching to a kernel
> task, but my Kernlish is very rusty, or maybe it has changed.
kernel threads do indeed preserve the mm of the old userspace task, but
we track that in ->active_m
On 07/28/2017 12:02 AM, Mathieu Desnoyers wrote:
- On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote:
[..
On Fri, Jul 28, 2017 at 10:37:25AM -0700, Andrew Hunter wrote:
> On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney
> wrote:
> > IPIin only those CPUs running threads in the same process as the
> > thread invoking membarrier() would be very nice! There is some LKML
> > discussion on this topic, w
- On Jul 28, 2017, at 1:31 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote:
>> On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney
>> wrote:
>> > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
>> >> IPIing onl
On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney
wrote:
> IPIin only those CPUs running threads in the same process as the
> thread invoking membarrier() would be very nice! There is some LKML
> discussion on this topic, which is currently circling around making this
> determination reliable on
On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote:
> On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney
> wrote:
> > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
> >> IPIing only running threads of my process would be perfect. In fact
> >> I might even be able to make us
- On Jul 28, 2017, at 1:15 PM, Andrew Hunter a...@google.com wrote:
> On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney
> wrote:
>> On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
>>> IPIing only running threads of my process would be perfect. In fact
>>> I might even be able to
On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney
wrote:
> On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
>> IPIing only running threads of my process would be perfect. In fact
>> I might even be able to make use of "membarrier these threads
>> please" to reduce IPIs, when I change t
- On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
> wrote:
>
>> On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote:
[...]
>>> >+
>>> >+ this_cpu = raw_smp_processor_
- On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote:
>> On 07/27/2017 10:43 PM, Paul E. McKenney wrote:
>> >On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
>> >>On 07/27/2017 09:12 PM, Paul
On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote:
> On 07/27/2017 10:43 PM, Paul E. McKenney wrote:
> >On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
> >>On 07/27/2017 09:12 PM, Paul E. McKenney wrote:
> >>>Hello!
> >>>
> >>>Please see below for a prototype sys_membarrier() s
On 07/27/2017 10:43 PM, Paul E. McKenney wrote:
On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
On 07/27/2017 09:12 PM, Paul E. McKenney wrote:
Hello!
Please see below for a prototype sys_membarrier() speedup patch.
Please note that there is some controversy on this subject, so the
On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
> On 07/27/2017 09:12 PM, Paul E. McKenney wrote:
> >Hello!
> >
> >Please see below for a prototype sys_membarrier() speedup patch.
> >Please note that there is some controversy on this subject, so the final
> >version will probably be qui
On 07/27/2017 09:12 PM, Paul E. McKenney wrote:
Hello!
Please see below for a prototype sys_membarrier() speedup patch.
Please note that there is some controversy on this subject, so the final
version will probably be quite a bit different than this prototype.
But my main question is whether th
On Thu, Jul 27, 2017 at 11:36:38AM -0700, Andrew Hunter wrote:
> On Thu, Jul 27, 2017 at 11:12 AM, Paul E. McKenney
> wrote:
> > Hello!
> > But my main question is whether the throttling shown below is acceptable
> > for your use cases, namely only one expedited sys_membarrier() permitted
> > per
On Thu, Jul 27, 2017 at 11:12 AM, Paul E. McKenney
wrote:
> Hello!
> But my main question is whether the throttling shown below is acceptable
> for your use cases, namely only one expedited sys_membarrier() permitted
> per scheduling-clock period (1 millisecond on many platforms), with any
> exces
Hello!
Please see below for a prototype sys_membarrier() speedup patch.
Please note that there is some controversy on this subject, so the final
version will probably be quite a bit different than this prototype.
But my main question is whether the throttling shown below is acceptable
for your us
20 matches
Mail list logo
