Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Sun, Nov 13, 2016 at 12:53:28PM -0600, Christoph Lameter wrote: > On Fri, 11 Nov 2016, Peter Zijlstra wrote: > > > On Fri, Nov 11, 2016 at 12:46:37PM -0600, Christoph Lameter wrote: > > > On Thu, 10 Nov 2016, Daniel Vacek wrote: > > > > > > > I believe Daniel's patches are the best thing we

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Sun, Nov 13, 2016 at 12:53:28PM -0600, Christoph Lameter wrote: > On Fri, 11 Nov 2016, Peter Zijlstra wrote: > > > On Fri, Nov 11, 2016 at 12:46:37PM -0600, Christoph Lameter wrote: > > > On Thu, 10 Nov 2016, Daniel Vacek wrote: > > > > > > > I believe Daniel's patches are the best thing we

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Fri, 11 Nov 2016, Peter Zijlstra wrote: > On Fri, Nov 11, 2016 at 12:46:37PM -0600, Christoph Lameter wrote: > > On Thu, 10 Nov 2016, Daniel Vacek wrote: > > > > > I believe Daniel's patches are the best thing we can do in current > > > situation as the behavior now seems rather buggy and does

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Fri, 11 Nov 2016, Peter Zijlstra wrote: > On Fri, Nov 11, 2016 at 12:46:37PM -0600, Christoph Lameter wrote: > > On Thu, 10 Nov 2016, Daniel Vacek wrote: > > > > > I believe Daniel's patches are the best thing we can do in current > > > situation as the behavior now seems rather buggy and does

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Fri, Nov 11, 2016 at 12:46:37PM -0600, Christoph Lameter wrote: > On Thu, 10 Nov 2016, Daniel Vacek wrote: > > > I believe Daniel's patches are the best thing we can do in current > > situation as the behavior now seems rather buggy and does not provide above > > mentioned expectations set

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Fri, Nov 11, 2016 at 12:46:37PM -0600, Christoph Lameter wrote: > On Thu, 10 Nov 2016, Daniel Vacek wrote: > > > I believe Daniel's patches are the best thing we can do in current > > situation as the behavior now seems rather buggy and does not provide above > > mentioned expectations set

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Thu, 10 Nov 2016, Daniel Vacek wrote: > I believe Daniel's patches are the best thing we can do in current > situation as the behavior now seems rather buggy and does not provide above > mentioned expectations set when rt throttling was merged with default > budget of 95% of CPU time. Nor if

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Thu, 10 Nov 2016, Daniel Vacek wrote: > I believe Daniel's patches are the best thing we can do in current > situation as the behavior now seems rather buggy and does not provide above > mentioned expectations set when rt throttling was merged with default > budget of 95% of CPU time. Nor if

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 08:50 PM, Peter Zijlstra wrote: >> The problem is that using RT_RUNTIME_SHARE a CPU will almost always >> > borrow enough runtime to make a CPU intensive rt task to run forever... >> > well not forever, but until the system crash because a kworker starved >> > in this CPU. Kworkers

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 08:50 PM, Peter Zijlstra wrote: >> The problem is that using RT_RUNTIME_SHARE a CPU will almost always >> > borrow enough runtime to make a CPU intensive rt task to run forever... >> > well not forever, but until the system crash because a kworker starved >> > in this CPU. Kworkers

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Steven Rostedt wrote: > On Mon, 7 Nov 2016 21:06:50 +0100 > Daniel Bristot de Oliveira wrote: > > > The throttling allowed the kworker to run, but once the kworker went to > > sleep, the RT tasks started to work again. In the previous behavior, > > the

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Steven Rostedt wrote: > On Mon, 7 Nov 2016 21:06:50 +0100 > Daniel Bristot de Oliveira wrote: > > > The throttling allowed the kworker to run, but once the kworker went to > > sleep, the RT tasks started to work again. In the previous behavior, > > the system would either go

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 08:29:49PM +0100, Daniel Bristot de Oliveira wrote: > > > On 11/08/2016 07:05 PM, Peter Zijlstra wrote: > >> > > >> > I know what we want to do, but there's some momentous problems that > >> > need to be solved first. > > Like what? > > The problem is that using

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 08:29:49PM +0100, Daniel Bristot de Oliveira wrote: > > > On 11/08/2016 07:05 PM, Peter Zijlstra wrote: > >> > > >> > I know what we want to do, but there's some momentous problems that > >> > need to be solved first. > > Like what? > > The problem is that using

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 07:05 PM, Peter Zijlstra wrote: >> > >> > I know what we want to do, but there's some momentous problems that >> > need to be solved first. > Like what? The problem is that using RT_RUNTIME_SHARE a CPU will almost always borrow enough runtime to make a CPU intensive rt task to

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 07:05 PM, Peter Zijlstra wrote: >> > >> > I know what we want to do, but there's some momentous problems that >> > need to be solved first. > Like what? The problem is that using RT_RUNTIME_SHARE a CPU will almost always borrow enough runtime to make a CPU intensive rt task to

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 12:17:10PM -0500, Steven Rostedt wrote: > On Tue, 8 Nov 2016 17:51:33 +0100 > Peter Zijlstra wrote: > > > You really should already know this. > > I know what we want to do, but there's some momentous problems that > need to be solved first. Like

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 12:17:10PM -0500, Steven Rostedt wrote: > On Tue, 8 Nov 2016 17:51:33 +0100 > Peter Zijlstra wrote: > > > You really should already know this. > > I know what we want to do, but there's some momentous problems that > need to be solved first. Like what? > Until then, we

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, 8 Nov 2016 17:51:33 +0100 Peter Zijlstra wrote: > You really should already know this. I know what we want to do, but there's some momentous problems that need to be solved first. Until then, we may be forced to continue with hacks. > > As stands the current rt

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, 8 Nov 2016 17:51:33 +0100 Peter Zijlstra wrote: > You really should already know this. I know what we want to do, but there's some momentous problems that need to be solved first. Until then, we may be forced to continue with hacks. > > As stands the current rt cgroup code (and all

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 09:07:40AM -0500, Steven Rostedt wrote: > On Tue, 8 Nov 2016 12:59:58 +0100 > Peter Zijlstra wrote: > > > No, none of this stands a chance of being accepted. > > > > This is making bad code worse. > > Peter, > > Instead of a flat out rejection,

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, Nov 08, 2016 at 09:07:40AM -0500, Steven Rostedt wrote: > On Tue, 8 Nov 2016 12:59:58 +0100 > Peter Zijlstra wrote: > > > No, none of this stands a chance of being accepted. > > > > This is making bad code worse. > > Peter, > > Instead of a flat out rejection, can you please provide

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, 8 Nov 2016 12:59:58 +0100 Peter Zijlstra wrote: > No, none of this stands a chance of being accepted. > > This is making bad code worse. Peter, Instead of a flat out rejection, can you please provide some constructive criticism to let those that are working on

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Tue, 8 Nov 2016 12:59:58 +0100 Peter Zijlstra wrote: > No, none of this stands a chance of being accepted. > > This is making bad code worse. Peter, Instead of a flat out rejection, can you please provide some constructive criticism to let those that are working on this know what would be

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

No, none of this stands a chance of being accepted. This is making bad code worse.

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

No, none of this stands a chance of being accepted. This is making bad code worse.

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

Hi Daniel, On 07/11/16 14:51, Daniel Bristot de Oliveira wrote: > On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote: [...] > > -) only issue might be that, if a non-RT task wakes up after the > > unthrottle, it will have to wait, but worst-case it will have a chance > > in the next throttling

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

Hi Daniel, On 07/11/16 14:51, Daniel Bristot de Oliveira wrote: > On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote: [...] > > -) only issue might be that, if a non-RT task wakes up after the > > unthrottle, it will have to wait, but worst-case it will have a chance > > in the next throttling

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

Hi all, since GRUB reclaiming has been mentioned, I am going to add some comments on it :) On Mon, 7 Nov 2016 14:51:37 +0100 Daniel Bristot de Oliveira wrote: [...] > The sum of allocated runtime for all DL tasks will not to be greater > than RT throttling enforcement

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

Hi all, since GRUB reclaiming has been mentioned, I am going to add some comments on it :) On Mon, 7 Nov 2016 14:51:37 +0100 Daniel Bristot de Oliveira wrote: [...] > The sum of allocated runtime for all DL tasks will not to be greater > than RT throttling enforcement runtime. The DL scheduler

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 21:33:02 +0100 Daniel Bristot de Oliveira wrote: > On 11/07/2016 09:16 PM, Steven Rostedt wrote: > > I'm confused? Are you saying that RR tasks don't get throttled in the > > current code? That sounds like a bug to me. > > If the RT_RUNTIME_SHARING is

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 21:33:02 +0100 Daniel Bristot de Oliveira wrote: > On 11/07/2016 09:16 PM, Steven Rostedt wrote: > > I'm confused? Are you saying that RR tasks don't get throttled in the > > current code? That sounds like a bug to me. > > If the RT_RUNTIME_SHARING is enabled, the CPU in

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 09:16 PM, Steven Rostedt wrote: > I'm confused? Are you saying that RR tasks don't get throttled in the > current code? That sounds like a bug to me. If the RT_RUNTIME_SHARING is enabled, the CPU in which the RR tasks are running (and pinned) will borrow RT runtime from another

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 09:16 PM, Steven Rostedt wrote: > I'm confused? Are you saying that RR tasks don't get throttled in the > current code? That sounds like a bug to me. If the RT_RUNTIME_SHARING is enabled, the CPU in which the RR tasks are running (and pinned) will borrow RT runtime from another

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 21:06:50 +0100 Daniel Bristot de Oliveira wrote: > The throttling allowed the kworker to run, but once the kworker went to > sleep, the RT tasks started to work again. In the previous behavior, > the system would either go idle, or the kworker would starve

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 21:06:50 +0100 Daniel Bristot de Oliveira wrote: > The throttling allowed the kworker to run, but once the kworker went to > sleep, the RT tasks started to work again. In the previous behavior, > the system would either go idle, or the kworker would starve because > the

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 09:00 PM, Steven Rostedt wrote: > On Mon, 7 Nov 2016 13:54:12 -0600 (CST) > Christoph Lameter wrote: > >> On Mon, 7 Nov 2016, Steven Rostedt wrote: >> >>> On Mon, 7 Nov 2016 13:30:15 -0600 (CST) >>> Christoph Lameter wrote: >>> SCHED_RR

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 09:00 PM, Steven Rostedt wrote: > On Mon, 7 Nov 2016 13:54:12 -0600 (CST) > Christoph Lameter wrote: > >> On Mon, 7 Nov 2016, Steven Rostedt wrote: >> >>> On Mon, 7 Nov 2016 13:30:15 -0600 (CST) >>> Christoph Lameter wrote: >>> SCHED_RR tasks alternately running on on cpu

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:30:15 -0600 (CST) Christoph Lameter wrote: > SCHED_RR tasks alternately running on on cpu can cause endless deferral of > kworker threads. With the global effect of the OS processing reserved > it may be the case that the processor we are executing never

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:30:15 -0600 (CST) Christoph Lameter wrote: > SCHED_RR tasks alternately running on on cpu can cause endless deferral of > kworker threads. With the global effect of the OS processing reserved > it may be the case that the processor we are executing never gets any > time.

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:54:12 -0600 (CST) Christoph Lameter wrote: > On Mon, 7 Nov 2016, Steven Rostedt wrote: > > > On Mon, 7 Nov 2016 13:30:15 -0600 (CST) > > Christoph Lameter wrote: > > > > > SCHED_RR tasks alternately running on on cpu can cause endless

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:54:12 -0600 (CST) Christoph Lameter wrote: > On Mon, 7 Nov 2016, Steven Rostedt wrote: > > > On Mon, 7 Nov 2016 13:30:15 -0600 (CST) > > Christoph Lameter wrote: > > > > > SCHED_RR tasks alternately running on on cpu can cause endless deferral of > > > kworker threads.

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Steven Rostedt wrote: > On Mon, 7 Nov 2016 13:30:15 -0600 (CST) > Christoph Lameter wrote: > > > SCHED_RR tasks alternately running on on cpu can cause endless deferral of > > kworker threads. With the global effect of the OS processing reserved > > it may be

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Steven Rostedt wrote: > On Mon, 7 Nov 2016 13:30:15 -0600 (CST) > Christoph Lameter wrote: > > > SCHED_RR tasks alternately running on on cpu can cause endless deferral of > > kworker threads. With the global effect of the OS processing reserved > > it may be the case that

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Steven Rostedt wrote: > On Mon, 7 Nov 2016 10:55:38 -0600 (CST) > Christoph Lameter wrote: > > > On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote: > > > > > With these two options set, the user will guarantee some runtime > > > for non-rt-tasks on all

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Steven Rostedt wrote: > On Mon, 7 Nov 2016 10:55:38 -0600 (CST) > Christoph Lameter wrote: > > > On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote: > > > > > With these two options set, the user will guarantee some runtime > > > for non-rt-tasks on all CPUs, while keeping

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 19:49:03 +0100 Daniel Bristot de Oliveira wrote: > On 11/07/2016 07:32 PM, Steven Rostedt wrote: > >> Excellent this would improve the situation with deadlocks as a result of > >> > cgroup_locks not being released due to lack of workqueue processing. > >

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 19:49:03 +0100 Daniel Bristot de Oliveira wrote: > On 11/07/2016 07:32 PM, Steven Rostedt wrote: > >> Excellent this would improve the situation with deadlocks as a result of > >> > cgroup_locks not being released due to lack of workqueue processing. > > ?? What deadlocks

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 07:32 PM, Steven Rostedt wrote: >> Excellent this would improve the situation with deadlocks as a result of >> > cgroup_locks not being released due to lack of workqueue processing. > ?? What deadlocks do you see? I mean, can you show the situation that > throttling RT tasks will

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 07:32 PM, Steven Rostedt wrote: >> Excellent this would improve the situation with deadlocks as a result of >> > cgroup_locks not being released due to lack of workqueue processing. > ?? What deadlocks do you see? I mean, can you show the situation that > throttling RT tasks will

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:30:46 -0500 Steven Rostedt wrote: > On Mon, 7 Nov 2016 12:22:21 -0600 > Clark Williams wrote: > > > I'm still reviewing the patch, but I have to wonder why bother with making > > it a scheduler feature? > > > > The SCHED_FIFO

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:30:46 -0500 Steven Rostedt wrote: > On Mon, 7 Nov 2016 12:22:21 -0600 > Clark Williams wrote: > > > I'm still reviewing the patch, but I have to wonder why bother with making > > it a scheduler feature? > > > > The SCHED_FIFO definition allows a fifo thread to starve

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 07:30 PM, Steven Rostedt wrote: >> I'm still reviewing the patch, but I have to wonder why bother with making >> it a scheduler feature? >> > >> > The SCHED_FIFO definition allows a fifo thread to starve others >> > because a fifo task will run until it yields. Throttling was

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/07/2016 07:30 PM, Steven Rostedt wrote: >> I'm still reviewing the patch, but I have to wonder why bother with making >> it a scheduler feature? >> > >> > The SCHED_FIFO definition allows a fifo thread to starve others >> > because a fifo task will run until it yields. Throttling was

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 10:55:38 -0600 (CST) Christoph Lameter wrote: > On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote: > > > With these two options set, the user will guarantee some runtime > > for non-rt-tasks on all CPUs, while keeping real-time tasks running > > as much as

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 10:55:38 -0600 (CST) Christoph Lameter wrote: > On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote: > > > With these two options set, the user will guarantee some runtime > > for non-rt-tasks on all CPUs, while keeping real-time tasks running > > as much as possible. > >

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 12:22:21 -0600 Clark Williams wrote: > I'm still reviewing the patch, but I have to wonder why bother with making it > a scheduler feature? > > The SCHED_FIFO definition allows a fifo thread to starve others > because a fifo task will run until it

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 12:22:21 -0600 Clark Williams wrote: > I'm still reviewing the patch, but I have to wonder why bother with making it > a scheduler feature? > > The SCHED_FIFO definition allows a fifo thread to starve others > because a fifo task will run until it yields. Throttling was

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 19:03:08 +0100 Tommaso Cucinotta wrote: > On 07/11/2016 14:51, Daniel Bristot de Oliveira wrote: > > Hi Tommaso, > > Hi, > > I'm cc-ing Luca for GRUB et al., pls find a few further notes below... Thanks Tommaso! I've seen the email on the

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 19:03:08 +0100 Tommaso Cucinotta wrote: > On 07/11/2016 14:51, Daniel Bristot de Oliveira wrote: > > Hi Tommaso, > > Hi, > > I'm cc-ing Luca for GRUB et al., pls find a few further notes below... Thanks Tommaso! I've seen the email on the linux-rt-users mailing list, and

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 09:17:55 +0100 Daniel Bristot de Oliveira wrote: > The rt throttling mechanism prevents the starvation of non-real-time > tasks by CPU intensive real-time tasks. In terms of percentage, > the default behavior allows real-time tasks to run up to 95% of a >

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 09:17:55 +0100 Daniel Bristot de Oliveira wrote: > The rt throttling mechanism prevents the starvation of non-real-time > tasks by CPU intensive real-time tasks. In terms of percentage, > the default behavior allows real-time tasks to run up to 95% of a > given period,

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 07/11/2016 14:51, Daniel Bristot de Oliveira wrote: Hi Tommaso, Hi, I'm cc-ing Luca for GRUB et al., pls find a few further notes below... On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote: as anticipated live to Daniel: -) +1 for the general concept, we'd need something similar also for

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 07/11/2016 14:51, Daniel Bristot de Oliveira wrote: Hi Tommaso, Hi, I'm cc-ing Luca for GRUB et al., pls find a few further notes below... On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote: as anticipated live to Daniel: -) +1 for the general concept, we'd need something similar also for

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote: > With these two options set, the user will guarantee some runtime > for non-rt-tasks on all CPUs, while keeping real-time tasks running > as much as possible. Excellent this would improve the situation with deadlocks as a result of

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote: > With these two options set, the user will guarantee some runtime > for non-rt-tasks on all CPUs, while keeping real-time tasks running > as much as possible. Excellent this would improve the situation with deadlocks as a result of

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

Hi Tommaso, On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote: > as anticipated live to Daniel: > -) +1 for the general concept, we'd need something similar also for > SCHED_DEADLINE Resumed: the sum of the runtime of deadline tasks will not be greater than the "to_ratio(global_rt_period(),

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

Hi Tommaso, On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote: > as anticipated live to Daniel: > -) +1 for the general concept, we'd need something similar also for > SCHED_DEADLINE Resumed: the sum of the runtime of deadline tasks will not be greater than the "to_ratio(global_rt_period(),

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

as anticipated live to Daniel: -) +1 for the general concept, we'd need something similar also for SCHED_DEADLINE -) only issue might be that, if a non-RT task wakes up after the unthrottle, it will have to wait, but worst-case it will have a chance in the next throttling window -) an

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

as anticipated live to Daniel: -) +1 for the general concept, we'd need something similar also for SCHED_DEADLINE -) only issue might be that, if a non-RT task wakes up after the unthrottle, it will have to wait, but worst-case it will have a chance in the next throttling window -) an

[PATCH] sched/rt: RT_RUNTIME_GREED sched feature

The rt throttling mechanism prevents the starvation of non-real-time tasks by CPU intensive real-time tasks. In terms of percentage, the default behavior allows real-time tasks to run up to 95% of a given period, leaving the other 5% of the period for non-real-time tasks. In the absence of non-rt

[PATCH] sched/rt: RT_RUNTIME_GREED sched feature

The rt throttling mechanism prevents the starvation of non-real-time tasks by CPU intensive real-time tasks. In terms of percentage, the default behavior allows real-time tasks to run up to 95% of a given period, leaving the other 5% of the period for non-real-time tasks. In the absence of non-rt