On Tue, 6 Oct 2020 11:35:23 +0200
Juri Lelli wrote:
[...]
> > > + if (dl_se->server_has_tasks(dl_se)) {
> > > + enqueue_dl_entity(dl_se, dl_se,
> > > ENQUEUE_REPLENISH);
> > > + resched_curr(rq);
> > > + __pus
Hi,
sorry for the late reply... Anyway, I am currently testing this
patchset (and trying to use it for the "SCHED_DEADLINE-based cgroup
scheduling" patchset).
And during my tests I had a doubt:
On Fri, 7 Aug 2020 11:50:49 +0200
Juri Lelli wrote:
> From: Peter Zijlstra
>
> Low priority task
Hi Juri,
thanks for sharing the v2 patchset!
In the next days I'll have a look at it, and try some tests...
In the meanwhile, I have some questions/comments after a first quick
look.
If I understand well, the patchset does not apply deadline servers to
FIFO and RR tasks, right? How does this pa
On Fri, 7 Aug 2020 15:43:53 +0200
Juri Lelli wrote:
> On 07/08/20 15:28, luca abeni wrote:
> > Hi Juri,
> >
> > On Fri, 7 Aug 2020 11:56:04 +0200
> > Juri Lelli wrote:
> >
> > > Starting deadline server for lower priority classes right away
>
Hi Peter,
On Fri, 7 Aug 2020 12:46:18 +0200
pet...@infradead.org wrote:
> On Fri, Aug 07, 2020 at 11:56:04AM +0200, Juri Lelli wrote:
> > Starting deadline server for lower priority classes right away when
> > first task is enqueued might break guarantees, as tasks belonging to
> > intermediate p
Hi Juri,
On Fri, 7 Aug 2020 15:30:41 +0200
Juri Lelli wrote:
[...]
> > In the meanwhile, I have some questions/comments after a first quick
> > look.
> >
> > If I understand well, the patchset does not apply deadline servers
> > to FIFO and RR tasks, right? How does this patchset interact with R
Hi Juri,
On Fri, 7 Aug 2020 11:56:04 +0200
Juri Lelli wrote:
> Starting deadline server for lower priority classes right away when
> first task is enqueued might break guarantees
Which guarantees are you thinking about, here? Response times of fixed
priority tasks?
If fixed priority tasks are
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 23e71d8ba42933bff12e453858fd68c073bc5258
Gitweb:
https://git.kernel.org/tip/23e71d8ba42933bff12e453858fd68c073bc5258
Author:Luca Abeni
AuthorDate:Wed, 20 May 2020 15:42:43 +02:00
Committer
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 60ffd5edc5e4fa69622c125c54ef8e7d5d894af8
Gitweb:
https://git.kernel.org/tip/60ffd5edc5e4fa69622c125c54ef8e7d5d894af8
Author:Luca Abeni
AuthorDate:Wed, 20 May 2020 15:42:41 +02:00
Committer
The following commit has been merged into the sched/core branch of tip:
Commit-ID: b4118988fdcb4554ea6687dd8ff68bcab690b8ea
Gitweb:
https://git.kernel.org/tip/b4118988fdcb4554ea6687dd8ff68bcab690b8ea
Author:Luca Abeni
AuthorDate:Wed, 20 May 2020 15:42:42 +02:00
Committer
On Wed, 31 Jul 2019 18:32:47 +0100
Dietmar Eggemann wrote:
[...]
> static void dequeue_dl_entity(struct sched_dl_entity *dl_se)
> {
> +if (!on_dl_rq(dl_se))
> +return;
> >>>
> >>> Why allow double dequeue instead of WARN?
> >>
> >> As I was saying
Hi Peter,
On Fri, 26 Jul 2019 16:54:09 +0200
Peter Zijlstra wrote:
> Hi,
>
> So recently syzcaller ran into the big deadline/period issue (again),
> and I figured I should at least propose a patch that puts limits on
> that -- see Patch 1.
>
> During that discussion; SCHED_OTHER servers got me
Hi,
On Fri, 26 Jul 2019 09:27:52 +0100
Dietmar Eggemann wrote:
[...]
> @@ -2121,17 +2121,13 @@ static int push_dl_task(struct rq *rq)
> }
>
> deactivate_task(rq, next_task, 0);
> - sub_running_bw(&next_task->dl, &rq->dl);
> - sub_rq_bw(&next_task->dl, &rq->dl);
> set_t
Hi Dietmar,
On Fri, 26 Jul 2019 09:27:56 +0100
Dietmar Eggemann wrote:
> To make the decision whether to set rq or running bw to 0 in underflow
> case use the return value of SCHED_WARN_ON() rather than an extra if
> condition.
I think I tried this at some point, but if I remember well this
sol
Hi Dietmar,
On Fri, 26 Jul 2019 09:27:52 +0100
Dietmar Eggemann wrote:
> push_dl_task() always calls deactivate_task() with flags=0 which sets
> p->on_rq=TASK_ON_RQ_MIGRATING.
Uhm... This is a recent change in the deactivate_task() behaviour,
right? Because I tested SCHED_DEADLINE a lot, but I'
Hi Peter,
On Mon, 8 Jul 2019 15:55:36 +0200
Peter Zijlstra wrote:
> On Mon, May 06, 2019 at 06:48:33AM +0200, Luca Abeni wrote:
> > @@ -1223,8 +1250,17 @@ static void update_curr_dl(struct rq *rq)
> > dl_se->dl_overrun = 1;
> >
> >
Hi Dietmar,
On Thu, 4 Jul 2019 14:05:22 +0200
Dietmar Eggemann wrote:
> On 5/6/19 6:48 AM, Luca Abeni wrote:
>
> [...]
>
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 5b981eeeb944..3436f3d8fa8f 100644
> > --- a/kernel/sched/dea
Hi Juri,
On Wed, 8 May 2019 15:10:18 +0200
Juri Lelli wrote:
> On 08/05/19 14:47, luca abeni wrote:
>
> [...]
>
> > Notice that all this logic is used only to select one of the idle
> > cores (instead of picking the first idle core, we select the less
> > powerfu
Hi Juri,
On Wed, 8 May 2019 14:05:26 +0200
Juri Lelli wrote:
[...]
> > > > + if ((rel_deadline < 0) || (rel_deadline *
> > > > dl_se->dl_runtime < dl_se->dl_deadline * rem_runtime)) {
> > > > + rel_deadline = dl_se->dl_deadline;
> > > > + rem_runtime = dl_se->dl
On Wed, 8 May 2019 11:08:55 +0200
Juri Lelli wrote:
> On 06/05/19 06:48, Luca Abeni wrote:
> > From: luca abeni
> >
> > Instead of considering the "static CPU bandwidth" allocated to
> > a SCHED_DEADLINE task (ratio between its maximum runtime and
&g
On Wed, 8 May 2019 10:04:36 +0200
Juri Lelli wrote:
> Hi Luca,
>
> On 06/05/19 06:48, Luca Abeni wrote:
> > From: luca abeni
> >
> > Currently, the SCHED_DEADLINE scheduler uses a global EDF scheduling
> > algorithm, migrating tasks to CPU cores without cons
Hi Juri,
On Wed, 8 May 2019 10:01:16 +0200
Juri Lelli wrote:
> Hi Luca,
>
> On 06/05/19 06:48, Luca Abeni wrote:
> > From: luca abeni
> >
> > Currently, the scheduler tries to find a proper placement for
> > SCHED_DEADLINE tasks when they are pushed out o
Hi Quentin,
On Tue, 7 May 2019 16:57:34 +0100
Quentin Perret wrote:
> On Monday 06 May 2019 at 06:48:36 (+0200), Luca Abeni wrote:
> > From: luca abeni
> >
> > When a task can fit on multiple CPU cores, try to select the slowest
> > core that is able to properly
Hi,
On Tue, 7 May 2019 15:10:50 +0100
Quentin Perret wrote:
> On Monday 06 May 2019 at 06:48:32 (+0200), Luca Abeni wrote:
> > static inline unsigned long cpu_bw_dl(struct rq *rq)
> > {
> > - return (rq->dl.running_bw * SCHED_CAPACITY_SCALE) >>
> >
On Tue, 7 May 2019 15:31:27 +0100
Quentin Perret wrote:
> On Tuesday 07 May 2019 at 16:25:23 (+0200), luca abeni wrote:
> > On Tue, 7 May 2019 14:48:52 +0100
> > Quentin Perret wrote:
> >
> > > Hi Luca,
> > >
> > > On Monday 06 May 2019 at 06
On Tue, 7 May 2019 14:48:52 +0100
Quentin Perret wrote:
> Hi Luca,
>
> On Monday 06 May 2019 at 06:48:31 (+0200), Luca Abeni wrote:
> > diff --git a/drivers/base/arch_topology.c
> > b/drivers/base/arch_topology.c index edfcf8d982e4..646d6d349d53
> > 100644 --- a/d
Hi Quentin,
On Tue, 7 May 2019 14:35:28 +0100
Quentin Perret wrote:
> Hi Luca,
>
> On Monday 06 May 2019 at 06:48:32 (+0200), Luca Abeni wrote:
> > +static inline int dl_task_fit(const struct sched_dl_entity *dl_se,
> > + int cpu, u64 *c)
&
From: luca abeni
Currently, the SCHED_DEADLINE scheduler uses a global EDF scheduling
algorithm, migrating tasks to CPU cores without considering the core
capacity and the task utilization. This works well on homogeneous
systems (SCHED_DEADLINE tasks are guaranteed to have a bounded
tardiness
From: luca abeni
When a task has a remaining runtime that cannot be served within the
scheduling deadline by anyone of the idle cores, the task is doomed
to miss its deadline (this can happen, because the admission control
only guarantees a bounded tardiness, not the hard respect of all
From: luca abeni
When a task can fit on multiple CPU cores, try to select the slowest
core that is able to properly serve the task. This avoids useless
future migrations, leaving the "fast cores" idle for more heavyweight
tasks.
Signed-off-by: luca abeni
---
kernel/sched/cpudeadl
From: luca abeni
Instead of considering the "static CPU bandwidth" allocated to
a SCHED_DEADLINE task (ratio between its maximum runtime and
reservation period), try to use the remaining runtime and time
to scheduling deadline.
Signed-off-by: luca abeni
---
kernel/sched/cpudead
From: luca abeni
Currently, the SCHED_DEADLINE admission control ensures that the
sum of reserved CPU bandwidths is smaller than x * M, where the
reserved CPU bandwidth of a SCHED_DEADLINE task is defined as the
ratio between its runtime and its period, x is a user-definable
percentage (95% by
From: luca abeni
Currently, the scheduler tries to find a proper placement for
SCHED_DEADLINE tasks when they are pushed out of a core or when
they wake up. Hence, if there is a single SCHED_DEADLINE task
that never blocks and wakes up, such a task is never migrated to
an appropriate CPU core
From: luca abeni
The SCHED_DEADLINE scheduling policy currently has some issues with
asymmetric CPU capacity architectures (such as ARM big.LITTLE).
In particular, the admission control mechanism does not work correctly
(because it considers all cores to have the same speed of the fastest
core
Commit-ID: 1b02cd6a2d7f3e2a6a5262887d2cb2912083e42f
Gitweb: https://git.kernel.org/tip/1b02cd6a2d7f3e2a6a5262887d2cb2912083e42f
Author: luca abeni
AuthorDate: Mon, 25 Mar 2019 14:15:30 +0100
Committer: Ingo Molnar
CommitDate: Tue, 16 Apr 2019 16:54:58 +0200
sched/deadline: Correctly
non_contending() is called) while the
0-lag timer is still active. In this case, the safest thing to
do is to immediately decrease the running bandwidth of the task,
without trying to re-arm the 0-lag timer.
Signed-off-by: luca abeni
---
kernel/sched/deadline.c | 3 +--
1 file changed, 1 insert
Hi Juri,
On Fri, 22 Mar 2019 15:32:32 +0100 Juri Lelli wrote:
[...]
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 6a73e41a2016..43901fa3f269 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -252,7 +252,6 @@ static void task_non_cont
Hi,
On Fri, 15 Mar 2019 08:43:00 +0800
"chengjian (D)" wrote:
[...]
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 6a73e41a2016..43901fa3f269 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -252,7 +252,6 @@ static void task_non_conte
Hi,
(I added Juri in cc)
On Tue, 12 Mar 2019 10:03:12 +0800
"chengjian (D)" wrote:
[...]
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 31c050a0d0ce..d73cb033a06d 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -252,7 +252,6 @@ static void ta
Hi all,
On Tue, 12 Mar 2019 10:03:12 +0800
"chengjian (D)" wrote:
> Hi.
>
> When looking to test SCHED_DEADLINE syzkaller report an warn in
> task_non_contending(). I tested the mainline kernel with the C program
> and captured the same call trace.
[...]
> diff --git a/kernel/sched/deadline.c b
Hi all,
(and, happy new year to everyone!)
this looks similar to a bug we have seen some time ago (a task
switching from SCHED_OTHER to SCHED_DEADLINE while inheriting a
deadline from a SCHED_DEADLINE task triggers the warning)...
Juri, I think you found a fix for such a bug; has it been committe
Hi all,
On Mon, 19 Nov 2018 09:23:03 +0100 (CET)
Thomas Gleixner wrote:
> Adding scheduler folks
>
> On Sun, 18 Nov 2018, syzbot wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:1ce80e0fe98e Merge tag 'fsnotify_for_v4.20-rc3' of
> > git://g.. git tree:
Hi Peter,
On Tue, 30 Oct 2018 11:45:54 +0100
Peter Zijlstra wrote:
[...]
> > 2. This is related to perf_event_open syscall reproducer does
> > before becoming DEADLINE and entering the busy loop. Enabling of
> > perf swevents generates lot of hrtimers load that happens in the
> > reproducer
On Fri, 19 Oct 2018 13:39:42 +0200
Peter Zijlstra wrote:
> On Thu, Oct 18, 2018 at 01:08:11PM +0200, luca abeni wrote:
> > Ok, I see the issue now: the problem is that the "while
> > (dl_se->runtime <= 0)" loop is executed at replenishment time, but
> >
Hi Juri,
On Thu, 18 Oct 2018 14:21:42 +0200
Juri Lelli wrote:
[...]
> > > > I missed the original emails, but maybe the issue is that the
> > > > task blocks before the tick, and when it wakes up again
> > > > something goes wrong with the deadline and runtime assignment?
> > > > (maybe because t
On Thu, 18 Oct 2018 12:47:13 +0200
Juri Lelli wrote:
> Hi,
>
> On 18/10/18 12:23, luca abeni wrote:
> > Hi Juri,
> >
> > On Thu, 18 Oct 2018 10:28:38 +0200
> > Juri Lelli wrote:
> > [...]
> > > struct sched_attr {
> > >
Hi Juri,
On Thu, 18 Oct 2018 12:10:08 +0200
Juri Lelli wrote:
[...]
> > Yes, a HZ related limit sounds like something we'd want. But if
> > we're going to do a minimum sysctl, we should also consider adding
> > a maximum, if you set a massive period/deadline, you can, even with
> > a relatively l
Hi Peter,
On Thu, 18 Oct 2018 11:48:50 +0200
Peter Zijlstra wrote:
[...]
> > So, I tend to think that we might want to play safe and put some
> > higher minimum value for dl_runtime (it's currently at 1ULL <<
> > DL_SCALE). Guess the problem is to pick a reasonable value, though.
> > Maybe link i
Hi Juri,
On Thu, 18 Oct 2018 10:28:38 +0200
Juri Lelli wrote:
[...]
> struct sched_attr {
> .size = 0,
> .policy = 6,
> .flags= 0,
> .nice = 0,
> .priority = 0,
> .runtime = 0x9917,
> .deadline = 0x,
> .period = 0,
> }
>
> So, we seem to be
On Thu, 11 Oct 2018 14:53:25 +0200
Peter Zijlstra wrote:
[...]
> > > > + if (rq->curr != rq->idle) {
> > > > + rq->proxy = rq->idle;
> > > > + set_tsk_need_resched(rq->idle);
> > > > + /*
> > > > +* XXX [juril] don't we still need to
Hi all,
On Tue, 9 Oct 2018 11:24:26 +0200
Juri Lelli wrote:
> Hi all,
>
> Proxy Execution (also goes under several other names) isn't a new
> concept, it has been mentioned already in the past to this community
> (both in email discussions and at conferences [1, 2]), but no actual
> implementa
On Wed, 10 Oct 2018 12:57:10 +0200
Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > So, I would propose to make the proxy() function of patch more
> > generic, and not strictly bound to mutexes. Maybe a task structure
> > can contai
Hi,
On Tue, 9 Oct 2018 11:24:31 +0200
Juri Lelli wrote:
[...]
> +migrate_task:
[...]
> + put_prev_task(rq, next);
> + if (rq->curr != rq->idle) {
> + rq->proxy = rq->idle;
> + set_tsk_need_resched(rq->idle);
> + /*
> + * XXX [juril] don't
Hi,
On Tue, 9 Oct 2018 11:24:29 +0200
Juri Lelli wrote:
> From: Peter Zijlstra
>
> Track the blocked-on relation for mutexes, this allows following this
> relation at schedule time. Add blocked_task to track the inverse
> relation.
>
> ,-> task
> | | block
nning_bw if the task is
> not queued and in non_contending state while switched to a different
> class.
>
> Reported-by: Mark Rutland
> Signed-off-by: Juri Lelli
> ---
> kernel/sched/deadline.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
Hi all,
sorry; I missed the beginning of this thread... Anyway, below I add
some comments:
On Wed, 6 Jun 2018 15:05:58 +0200
Claudio Scordino wrote:
[...]
> >> Ok, I see ... Have you guys already tried something like my patch
> >> above (keeping the freq >= this_bw) in real world use cases ? Is
Hi,
On Wed, 6 Jun 2018 14:20:46 +0100
Quentin Perret wrote:
[...]
> > However, IMHO, these are corner cases and in the average case it is
> > better to rely on running_bw and reduce the CPU frequency
> > accordingly.
>
> My point was that accepting to go at a lower frequency than required
> by
Hi Mathieu,
On Thu, 1 Feb 2018 09:51:02 -0700
Mathieu Poirier wrote:
> This is the follow-up patchset to [1] that attempt to fix a problem
> reported by Steve Rostedt [2] where DL bandwidth accounting is not
> recomputed after CPUset and CPU hotplug operations. When CPU hotplug and
> some CUPs
On Sat, 25 Nov 2017 21:46:11 -0800
Jakub Kicinski wrote:
> Hi!
>
> Did these:
>
> ./include/linux/sched.h:476:62: error: dubious one-bit signed bitfield
> ./include/linux/sched.h:477:62: error: dubious one-bit signed bitfield
> ./include/linux/sched.h:478:62: error: dubious one-bit signed bitfi
laints about this very issue when
> compiling any code that includes sched.h.
>
> Fixes: 799ba82de01e ("sched/deadline: Use C bitfields for the state flags")
> Cc: luca abeni
> Cc: Peter Zijlstra (Intel)
> Cc: Daniel Bristot de Oliveira
> Cc: Juri Lelli
> Cc: L
Hi,
On Fri, 17 Nov 2017 14:50:11 +0800
Xin Long wrote:
> This patch is to fix the 'dubious one-bit signed bitfield' error reported
> by sparse, when using 'make C=2'.
>
> Fixes: 799ba82de01e ("sched/deadline: Use C bitfields for the state flags")
> Signed-off-by: Xin Long
I think this is very
Hi,
On Tue, 14 Nov 2017 12:41:35 -0800
Matthew Wilcox wrote:
> commit 799ba82de01e7543f6b2042e1a739f3a20255f23
> Author: luca abeni
> Date: Thu Sep 7 12:09:31 2017 +0200
>
> sched/deadline: Use C bitfields for the state flags
>
> Ask the compiler to use a s
of places
> so Sparse generates a flood of warnings like this:
>
> ./include/linux/sched.h:477:54: error: dubious one-bit signed bitfield
>
> Signed-off-by: Dan Carpenter
I did not notice any issue when testing, but if "unsigned int" is the
common practice for bitfields, I
Hi Mathieu,
On Thu, 12 Oct 2017 10:57:09 -0600
Mathieu Poirier wrote:
[...]
> >> Regardless of how we proceed (using existing CPUset list or new ones) we
> >> need to deal with DL tasks that span more than one root domain, something
> >> that will typically happen after a CPUset operation. For
Commit-ID: 799ba82de01e7543f6b2042e1a739f3a20255f23
Gitweb: https://git.kernel.org/tip/799ba82de01e7543f6b2042e1a739f3a20255f23
Author: luca abeni
AuthorDate: Thu, 7 Sep 2017 12:09:31 +0200
Committer: Ingo Molnar
CommitDate: Tue, 10 Oct 2017 11:45:26 +0200
sched/deadline: Use C
Commit-ID: 295d6d5e373607729bcc8182c25afe964655714f
Gitweb: https://git.kernel.org/tip/295d6d5e373607729bcc8182c25afe964655714f
Author: Luca Abeni
AuthorDate: Thu, 7 Sep 2017 12:09:29 +0200
Committer: Ingo Molnar
CommitDate: Tue, 10 Oct 2017 11:43:30 +0200
sched/deadline: Fix
Commit-ID: e964d3501b64d6930aaa4dd18955a8cd086ccb92
Gitweb: https://git.kernel.org/tip/e964d3501b64d6930aaa4dd18955a8cd086ccb92
Author: luca abeni
AuthorDate: Thu, 7 Sep 2017 12:09:28 +0200
Committer: Ingo Molnar
CommitDate: Tue, 10 Oct 2017 11:43:30 +0200
sched/headers: Remove
amp;" and "|").
Signed-off-by: luca abeni
---
include/linux/sched.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 68b3833..e03cc69 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -
patch fixes the problem by initializing the task's parameters before
enqueuing it.
Signed-off-by: luca abeni
Reviewed-by: Daniel Bristot de Oliveira
---
kernel/sched/deadline.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/
From: Peter Zijlstra
__dl_sub() is more meaningful as a name, and is more consistent
with the naming of the dual function (__dl_add()).
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: luca abeni
---
kernel/sched/deadline.c | 10 +-
kernel/sched/sched.h| 2 +-
2 files
Signed-off-by: luca abeni
---
kernel/sched/sched.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 1043c8b..0b93e4b 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -255,7 +255,6 @@ extern int sched_dl_overflow(struct
Patch 0004 saves reduces the size of sched_dl_entity by using bitfields
instead of whole integers for boolean values.
Peter Zijlstra (1):
sched/deadline: rename __dl_clear() to __dl_sub()
luca abeni (3):
sched/sched.h: remove duplicate prototype of __dl_clear_params()
sched/deadline
Hi Mathieu,
On Wed, 23 Aug 2017 13:47:13 -0600
Mathieu Poirier wrote:
> On 22 August 2017 at 06:21, Luca Abeni wrote:
> > Hi Mathieu,
>
> Good day to you,
>
> >
> > On Wed, 16 Aug 2017 15:20:36 -0600
> > Mathieu Poirier wrote:
> >
> >
On Fri, 25 Aug 2017 08:02:43 +0200
luca abeni wrote:
[...]
> > The above demonstrate that even if we have two CPUsets new task belong
> > to the "default" CPUset and as such can use all the available CPUs.
>
> I still have a doubt (probably showing all my ignora
Hi Mathieu,
On Thu, 24 Aug 2017 14:32:20 -0600
Mathieu Poirier wrote:
[...]
> >> > if we want to create some "second level cpusets" inside a "parent
> >> > cpuset", allowing deadline tasks to be placed inside both the
> >> > "parent cpuset" and the "second level cpusets", then we have to
> >> > s
On Wed, 23 Aug 2017 13:47:13 -0600
Mathieu Poirier wrote:
> >> This is a renewed attempt at fixing a problem reported by Steve Rostedt [1]
> >> where DL bandwidth accounting is not recomputed after CPUset and CPUhotplug
> >> operations. When CPUhotplug and some CUPset manipulation take place root
Hi Mathieu,
On Wed, 16 Aug 2017 15:20:36 -0600
Mathieu Poirier wrote:
> This is a renewed attempt at fixing a problem reported by Steve Rostedt [1]
> where DL bandwidth accounting is not recomputed after CPUset and CPUhotplug
> operations. When CPUhotplug and some CUPset manipulation take place
On Tue, 25 Jul 2017 15:51:05 +0200
Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 09:03:08AM +0200, Luca Abeni wrote:
>
> > > I'm still confused..
> > >
> > > So GRUB does:
> > >
> > > dq = Uact -dt
> > >
> > > righ
Hi Peter,
On Mon, 24 Jul 2017 18:43:49 +0200
Peter Zijlstra wrote:
> On Wed, Jul 19, 2017 at 12:16:24PM +0100, Juri Lelli wrote:
> > On 19/07/17 13:00, Peter Zijlstra wrote:
> > > On Wed, Jul 19, 2017 at 10:20:29AM +0100, Juri Lelli wrote:
> > > > On 19/07/17 09:21, Peter Zijlstra wrote:
>
On Mon, 24 Jul 2017 11:11:30 +0200
Peter Zijlstra wrote:
> On Mon, Jul 24, 2017 at 09:54:54AM +0200, Luca Abeni wrote:
> > Hi Peter,
> >
> > I put this change in a local tree together with other fixes / cleanups
> > I plan to submit in the next weeks. Should
On Mon, 24 Jul 2017 11:04:52 +0200
Peter Zijlstra wrote:
> On Mon, Jul 24, 2017 at 10:06:09AM +0200, Luca Abeni wrote:
> > > Yes, grouping all the flags in a single field was my intention too... I
> > > planned to submit a patch to do this after merging the reclaiming
>
know.
Thanks,
Luca
On Thu, 20 Apr 2017 21:30:56 +0200
luca abeni wrote:
> From: Luca Abeni
>
> When switching to -deadline, if the scheduling deadline of a task is
> in the past then switched_to_dl() calls setup_new_entity()
Hi Peter,
On Fri, 24 Mar 2017 22:47:15 +0100
luca abeni wrote:
> Hi Peter,
>
> On Fri, 24 Mar 2017 14:20:41 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Mar 24, 2017 at 04:52:55AM +0100, luca abeni wrote:
> >
> > > diff --git a/include/linux/sched.h
getting this wrong every time :)
Thanks,
Luca
On Fri, 24 Mar 2017 14:23:51 +0100
Peter Zijlstra wrote:
> On Fri, Mar 24, 2017 at 04:52:55AM +0100, luca abeni wrote:
> > @@ -2518,6 +2520,7 @@ static int dl_overflow(struct task_struc
ct sched_dl_entity *dl_se)
> +static u64 grub_reclaim(u64 delta, struct rq *rq, struct sched_dl_entity
> *dl_se)
> {
> u64 u_inact = rq->dl.this_bw - rq->dl.running_bw; /* Utot - Uact */
> u64 u_act;
Looks good; thanks for fixing this (and sorry for introducing the
warning).
Acked-by: Luca Abeni
Luca
Commit-ID: daec5798367012951cdb54fdb5c006e4379c9ae9
Gitweb: http://git.kernel.org/tip/daec5798367012951cdb54fdb5c006e4379c9ae9
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:36 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:55 +0200
sched/deadline: Reclaim
Commit-ID: 9f0d1a5077399143aad7e1244bb031e29116074e
Gitweb: http://git.kernel.org/tip/9f0d1a5077399143aad7e1244bb031e29116074e
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:35 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:54 +0200
sched/deadline: Base GRUB
Commit-ID: 8fd27231c3302e0c7e1907df1252db97b65eb241
Gitweb: http://git.kernel.org/tip/8fd27231c3302e0c7e1907df1252db97b65eb241
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:34 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:53 +0200
sched/deadline: Track the
Commit-ID: 2d4283e9d583a3ee8cfb1cbb9c1270614df4c29d
Gitweb: http://git.kernel.org/tip/2d4283e9d583a3ee8cfb1cbb9c1270614df4c29d
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:33 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:52 +0200
sched/deadline: Make GRUB a
Commit-ID: 4da3abcefe178c650033f371e94fa10e80bce167
Gitweb: http://git.kernel.org/tip/4da3abcefe178c650033f371e94fa10e80bce167
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:32 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:51 +0200
sched/deadline: Do not
Commit-ID: 387e31300b5760169e6d3f7a9e1eeed12cc5a30b
Gitweb: http://git.kernel.org/tip/387e31300b5760169e6d3f7a9e1eeed12cc5a30b
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:30 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:50 +0200
sched/deadline: Fix the
Commit-ID: c52f14d384628db0217a7a9080ab800d5ffb2d72
Gitweb: http://git.kernel.org/tip/c52f14d384628db0217a7a9080ab800d5ffb2d72
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:31 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:51 +0200
sched/deadline: Implement
Commit-ID: e36d8677bfa55054e4194ec3683189b882a538f6
Gitweb: http://git.kernel.org/tip/e36d8677bfa55054e4194ec3683189b882a538f6
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:28 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:27:56 +0200
sched/deadline: Track the
Commit-ID: 209a0cbda7a01d2ea32a8b631d35e873bee498e9
Gitweb: http://git.kernel.org/tip/209a0cbda7a01d2ea32a8b631d35e873bee498e9
Author: Luca Abeni
AuthorDate: Thu, 18 May 2017 22:13:29 +0200
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:31:49 +0200
sched/deadline: Improve the
On Thu, 8 Jun 2017 10:31:25 +0200
Ingo Molnar wrote:
> * luca abeni wrote:
>
> > From: Luca Abeni
> >
> > Active utilization is defined as the total utilization of active
> > (TASK_RUNNING) tasks queued on a runqueue. Hence, it is increased
> > when a t
On Wed, 24 May 2017 10:25:05 +0100
Juri Lelli wrote:
> Hi,
>
> On 23/05/17 22:23, Peter Zijlstra wrote:
> > On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote:
> >
> > > A point that is still very much up for discussion (more that the
> > > others :) is how we implement frequency/cpu
From: Luca Abeni
According to the GRUB (Greedy Reclaimation of Unused Bandwidth)
reclaiming algorithm, the runtime is not decreased as "dq = -dt",
but as "dq = -Uact dt" (where Uact is the per-runqueue active
utilization).
Hence, this commit modifies the runtime accounting ru
From: Luca Abeni
This commit introduces a per-runqueue "extra utilization" that can be
reclaimed by deadline tasks. In this way, the maximum fraction of CPU
time that can reclaimed by deadline tasks is fixed (and configurable)
and does not depend on the total deadline utilization
From: Claudio Scordino
This patch adds the documentation about the GRUB reclaiming algorithm,
adding a few details discussed in list.
Signed-off-by: Claudio Scordino
Signed-off-by: Luca Abeni
---
Documentation/scheduler/sched-deadline.txt | 168 +
1 file changed
From: Luca Abeni
Instead of decreasing the runtime as "dq = -Uact dt" (eventually
divided by the maximum utilization available for deadline tasks),
decrease it as "dq = -max{u, (1 - Uinact)} dt", where u is the task
utilization and Uinact is the "inactive utilization&q
1 - 100 of 376 matches
Mail list logo
