Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

> 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 =

Re: [PATCH v15 04/13] task_isolation: add initial support

> 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 =

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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, >

Re: [PATCH v15 04/13] task_isolation: add initial support

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, >

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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,

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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 >

Re: [PATCH v15 04/13] task_isolation: add initial support

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 >

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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.

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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: > >

Re: [PATCH v15 04/13] task_isolation: add initial support

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,

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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,

Re: [PATCH v15 04/13] task_isolation: add initial support

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:

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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?

Re: [PATCH v15 04/13] task_isolation: add initial support

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?

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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,

Re: [PATCH v15 04/13] task_isolation: add initial support

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,

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

Re: [PATCH v15 04/13] task_isolation: add initial support

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

[PATCH v15 04/13] task_isolation: add initial support

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

[PATCH v15 04/13] task_isolation: add initial support

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