On 2/2/2017 11:13 AM, Eugene Syromiatnikov wrote:
case PR_GET_FP_MODE:
error = GET_FP_MODE(me);
break;
+#ifdef CONFIG_TASK_ISOLATION
+ case PR_SET_TASK_ISOLATION:
+ error = task_isolation_set(arg2);
+ break;
+ case PR
> case PR_GET_FP_MODE:
> error = GET_FP_MODE(me);
> break;
> +#ifdef CONFIG_TASK_ISOLATION
> + case PR_SET_TASK_ISOLATION:
> + error = task_isolation_set(arg2);
> + break;
> + case PR_GET_TASK_ISOLATION:
> + error = me->t
On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
We really want to run task isolation last, so we can guarantee that
all the isolation prerequisites are met (dynticks stopped, per-cpu lru
cache empty, etc). But achieving that state can require enabl
On Tue, Sep 27, 2016 at 04:39:26PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 27, 2016 at 04:22:20PM +0200, Frederic Weisbecker wrote:
>
> > The RCU context tracking doesn't take care of callbacks. It's only there
> > to tell the RCU core whether the CPU runs code that may or may not run
> > RCU r
On Tue, Sep 27, 2016 at 04:22:20PM +0200, Frederic Weisbecker wrote:
> On Fri, Sep 02, 2016 at 10:28:00AM -0700, Andy Lutomirski wrote:
> >
> > Unless I'm missing something (which is reasonably likely), couldn't
> > the isolation code just force or require rcu_nocbs on the isolated
> > CPUs to avo
On Tue, Sep 27, 2016 at 04:22:20PM +0200, Frederic Weisbecker wrote:
> The RCU context tracking doesn't take care of callbacks. It's only there
> to tell the RCU core whether the CPU runs code that may or may not run
> RCU read side critical sections. This is assumed by "kernel may use RCU,
> user
On Fri, Sep 02, 2016 at 10:28:00AM -0700, Andy Lutomirski wrote:
>
> Unless I'm missing something (which is reasonably likely), couldn't
> the isolation code just force or require rcu_nocbs on the isolated
> CPUs to avoid this problem entirely.
rcu_nocb is already implied by nohz_full. Which mean
On 9/12/2016 1:41 PM, Andy Lutomirski wrote:
On Sep 9, 2016 1:40 PM, "Chris Metcalf" wrote:
On 9/2/2016 1:28 PM, Andy Lutomirski wrote:
On Sep 2, 2016 7:04 AM, "Chris Metcalf" wrote:
On 8/30/2016 3:50 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf wrote:
So to
On Sep 9, 2016 1:40 PM, "Chris Metcalf" wrote:
>
> On 9/2/2016 1:28 PM, Andy Lutomirski wrote:
>>
>> On Sep 2, 2016 7:04 AM, "Chris Metcalf" wrote:
>>>
>>> On 8/30/2016 3:50 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf
wrote:
>
> On 8/30/2016
On 9/2/2016 1:28 PM, Andy Lutomirski wrote:
On Sep 2, 2016 7:04 AM, "Chris Metcalf" wrote:
On 8/30/2016 3:50 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf wrote:
On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
What if we did it the other way around: set a percpu fl
On Sep 2, 2016 7:04 AM, "Chris Metcalf" wrote:
>
> On 8/30/2016 3:50 PM, Andy Lutomirski wrote:
>>
>> On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf
>> wrote:
>>>
>>> On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
What if we did it the other way around: set a percpu flag saying
"go
On Fri, Sep 02, 2016 at 10:03:52AM -0400, Chris Metcalf wrote:
> Any thoughts on the question of "just re-enter the loop" vs.
> schedule_timeout()?
schedule_timeout() should only be used for things you do not have
control over, like things outside of the machine.
If you want to actually block ru
On 8/30/2016 3:50 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf wrote:
On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
What if we did it the other way around: set a percpu flag saying
"going quiescent; disallow new deferred work", then finish all
existing work and ret
On 9/1/2016 6:06 AM, Peter Zijlstra wrote:
On Tue, Aug 30, 2016 at 11:32:16AM -0400, Chris Metcalf wrote:
On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
What !? I really don't get this, what are you waiting for? Why is
rescheduling making things better.
We need to wait for the last dyntick to fir
On Tue, Aug 30, 2016 at 11:32:16AM -0400, Chris Metcalf wrote:
> On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
> >What !? I really don't get this, what are you waiting for? Why is
> >rescheduling making things better.
>
> We need to wait for the last dyntick to fire before we can return to
> usersp
On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
The basic idea is just that we don't want to be at risk from the
dyntick getting enabled. Similar
On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf wrote:
> On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
>>
>> On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
>>>
>>> On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf
wrote:
>
> The
On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
>
> On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
>>
>> On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
>>>
>>> On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
>
> O
On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
> On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
>>
>> On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
>>>
>>> On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
>>>
On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
+ /*
+* Request rescheduling unless we are in full dynticks mode.
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
> On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
> >On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
> >>+ /*
> >>+* Request rescheduling unless we are in full dynticks mode.
> >>+* We would eventually get pre-empt
On Mon, Aug 29, 2016 at 12:53:30PM -0400, Chris Metcalf wrote:
> Would it be cleaner to just replace the set_tsk_need_resched() call
> with something like:
>
> set_current_state(TASK_INTERRUPTIBLE);
> schedule();
> __set_current_state(TASK_RUNNING);
>
> or what would you recommend?
On 8/29/2016 12:48 PM, Peter Zijlstra wrote:
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
+ /*
+* Request rescheduling unless we are in full dynticks mode
On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
+ /*
+* Request rescheduling unless we are in full dynticks mode.
+* We would eventually get pre-empted without this, and if
+* there's another task waiting,
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
> On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
> >On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
> >>+ /*
> >>+* Request rescheduling unless we are in full dynticks mode.
> >>+* We would eventually get pre-empt
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
> + /*
> + * Request rescheduling unless we are in full dynticks mode.
> + * We would eventually get pre-empted without this, and if
> + * there's another task waiting, it would run; but by
> + * explicitly reque
The existing nohz_full mode is designed as a "soft" isolation mode
that makes tradeoffs to minimize userspace interruptions while
still attempting to avoid overheads in the kernel entry/exit path,
to provide 100% kernel semantics, etc.
However, some applications require a "hard" commitment from th
28 matches
Mail list logo
