On Tue, 23 Feb 2016 13:28:22 +0100
Peter Zijlstra wrote:
> Would something like this make sense instead?
It works perfectly.
Reported-by: Steven Rostedt
Tested-by: Steven Rostedt
Thanks!
-- Steve
>
> It also retains the
On Tue, 23 Feb 2016 13:28:22 +0100
Peter Zijlstra wrote:
> Would something like this make sense instead?
It works perfectly.
Reported-by: Steven Rostedt
Tested-by: Steven Rostedt
Thanks!
-- Steve
>
> It also retains the ->runtime while yielded, and would actually 'fix' a
> case where,
On Tue, 23 Feb 2016 13:28:22 +0100
Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 06:10:20PM -0500, Steven Rostedt wrote:
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index cd64c979d0e1..1dd180cda574 100644
> > --- a/kernel/sched/deadline.c
> >
On Tue, 23 Feb 2016 13:28:22 +0100
Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 06:10:20PM -0500, Steven Rostedt wrote:
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index cd64c979d0e1..1dd180cda574 100644
> > --- a/kernel/sched/deadline.c
> > +++
On Fri, Feb 12, 2016 at 06:10:20PM -0500, Steven Rostedt wrote:
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index cd64c979d0e1..1dd180cda574 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -735,7 +735,7 @@ static void update_curr_dl(struct rq *rq)
On Fri, Feb 12, 2016 at 06:10:20PM -0500, Steven Rostedt wrote:
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index cd64c979d0e1..1dd180cda574 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -735,7 +735,7 @@ static void update_curr_dl(struct rq *rq)
On Mon, 15 Feb 2016 10:18:24 +
Juri Lelli wrote:
> > Signed-off-by: Steven Rostedt
> > ---
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index cd64c979d0e1..1dd180cda574 100644
> > --- a/kernel/sched/deadline.c
> > +++
On Mon, 15 Feb 2016 10:18:24 +
Juri Lelli wrote:
> > Signed-off-by: Steven Rostedt
> > ---
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index cd64c979d0e1..1dd180cda574 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -735,7 +735,7
On 02/15/2016 08:18 AM, Juri Lelli wrote:
> Do you think we could also skip some of the
> following updates/accounting in this case? Not sure we win anything by
> doing that, though.
I reviewed rostedt's patch and the following updates/accounting
operations. I agree with rostedt's patch, and
On 02/15/2016 08:18 AM, Juri Lelli wrote:
> Do you think we could also skip some of the
> following updates/accounting in this case? Not sure we win anything by
> doing that, though.
I reviewed rostedt's patch and the following updates/accounting
operations. I agree with rostedt's patch, and
Hi,
On 12/02/16 18:10, Steven Rostedt wrote:
> I'm writing a test case for SCHED_DEADLINE, and notice a strange
> anomaly. Every so often, a deadline is missed and when I looked into
> it, it happened because the sched_yield() had no effect (it didn't end
> the previous period and let the start
Hi,
On 12/02/16 18:10, Steven Rostedt wrote:
> I'm writing a test case for SCHED_DEADLINE, and notice a strange
> anomaly. Every so often, a deadline is missed and when I looked into
> it, it happened because the sched_yield() had no effect (it didn't end
> the previous period and let the start
I'm writing a test case for SCHED_DEADLINE, and notice a strange
anomaly. Every so often, a deadline is missed and when I looked into
it, it happened because the sched_yield() had no effect (it didn't end
the previous period and let the start of the next runtime happen on the
end of the old
I'm writing a test case for SCHED_DEADLINE, and notice a strange
anomaly. Every so often, a deadline is missed and when I looked into
it, it happened because the sched_yield() had no effect (it didn't end
the previous period and let the start of the next runtime happen on the
end of the old
14 matches
Mail list logo