Re: [RFC PATCH v2 4/6] sched/deadline: Introduce deadline servers

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); > > > +

Re: [RFC PATCH v2 4/6] sched/deadline: Introduce deadline servers

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

Re: [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure

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

Re: [RFC PATCH v2 6/6] sched/fair: Implement starvation monitor

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 >

Re: [RFC PATCH v2 6/6] sched/fair: Implement starvation monitor

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

Re: [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure

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

Re: [RFC PATCH v2 6/6] sched/fair: Implement starvation monitor

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

[tip: sched/core] sched/deadline: Implement fallback mechanism for !fit case

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

[tip: sched/core] sched/deadline: Improve admission control for asymmetric CPU capacities

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

[tip: sched/core] sched/deadline: Make DL capacity-aware

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

Re: [PATCH 4/5] sched/deadline: Cleanup on_dl_rq() handling

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

Re: [RFC][PATCH 00/13] SCHED_DEADLINE server infrastructure

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

Re: [PATCH 1/5] sched/deadline: Fix double accounting of rq/running bw in push_dl_task()

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(_task->dl, >dl); > - sub_rq_bw(_task->dl, >dl); >

Re: [PATCH 5/5] sched/deadline: Use return value of SCHED_WARN_ON() in bw accounting

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

Re: [PATCH 1/5] sched/deadline: Fix double accounting of rq/running bw in push_dl_task()

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

Re: [RFC PATCH 3/6] sched/dl: Try better placement even for deadline tasks that do not block

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

Re: [RFC PATCH 2/6] sched/dl: Capacity-aware migrations

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

Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup

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

Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup

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 =

Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup

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 an

Re: [RFC PATCH 2/6] sched/dl: Capacity-aware migrations

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

Re: [RFC PATCH 3/6] sched/dl: Try better placement even for deadline tasks that do not block

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

Re: [RFC PATCH 6/6] sched/dl: Try not to select a too fast core

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

Re: [RFC PATCH 2/6] sched/dl: Capacity-aware migrations

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

Re: [RFC PATCH 1/6] sched/dl: Improve deadline admission control for asymmetric CPU capacities

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

Re: [RFC PATCH 1/6] sched/dl: Improve deadline admission control for asymmetric CPU capacities

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

Re: [RFC PATCH 2/6] sched/dl: Capacity-aware migrations

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) &

[RFC PATCH 2/6] sched/dl: Capacity-aware migrations

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

[RFC PATCH 5/6] sched/dl: If the task does not fit anywhere, select the fastest core

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

[RFC PATCH 6/6] sched/dl: Try not to select a too fast core

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

[RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup

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

[RFC PATCH 1/6] sched/dl: Improve deadline admission control for asymmetric CPU capacities

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

[RFC PATCH 3/6] sched/dl: Try better placement even for deadline tasks that do not block

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

[RFC PATCH 0/6] Capacity awareness for SCHED_DEADLINE

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

[tip:sched/urgent] sched/deadline: Correctly handle active 0-lag timers

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

[PATCH] sched/deadline: correctly handle active 0-lag timers

_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 insertion(

Re: WARN ON at kernel/sched/deadline.c task_non_contending

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

Re: WARN ON at kernel/sched/deadline.c task_non_contending

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

Re: WARN ON at kernel/sched/deadline.c task_non_contending

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

Re: WARN ON at kernel/sched/deadline.c task_non_contending

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

Re: WARNING in enqueue_task_dl

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

Re: WARNING in enqueue_task_dl

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

Re: WARNING in enqueue_task_dl

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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 >

Re: INFO: rcu detected stall in do_idle

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 >

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: INFO: rcu detected stall in do_idle

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

Re: [RFD/RFC PATCH 5/8] sched: Add proxy execution

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

Re: [RFD/RFC PATCH 5/8] sched: Add proxy execution

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

Re: [RFD/RFC PATCH 0/8] Towards implementing proxy execution

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 >

Re: [RFD/RFC PATCH 0/8] Towards implementing proxy execution

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 >

Re: [RFD/RFC PATCH 0/8] Towards implementing proxy execution

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 co

Re: [RFD/RFC PATCH 0/8] Towards implementing proxy execution

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 co

Re: [RFD/RFC PATCH 5/8] sched: Add proxy execution

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

Re: [RFD/RFC PATCH 5/8] sched: Add proxy execution

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

Re: [RFD/RFC PATCH 3/8] locking/mutex: Rework task_struct::blocked_on

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

Re: [RFD/RFC PATCH 3/8] locking/mutex: Rework task_struct::blocked_on

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

Re: [PATCH] sched/deadline: Fix switched_from_dl

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(-)

Re: [PATCH] sched/deadline: Fix switched_from_dl

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(-)

Re: [PATCH v5 00/10] track CPU utilization

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

Re: [PATCH v5 00/10] track CPU utilization

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

Re: [PATCH v5 00/10] track CPU utilization

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 >

Re: [PATCH v5 00/10] track CPU utilization

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 >

Re: [PATCH V2 0/7] sched/deadline: fix cpusets bandwidth accounting

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.

Re: [PATCH V2 0/7] sched/deadline: fix cpusets bandwidth accounting

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

Re: Sparse warnings from sched.h

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

Re: Sparse warnings from sched.h

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

Re: [PATCH] sched/deadline: Use bools for the state flags

This also silences annoying sparse complaints 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 <luca.ab...@santannapisa.it> > Cc: Peter Zijlstra (In

Re: [PATCH] sched/deadline: Use bools for the state flags

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

Re: [PATCH] sched: use unsigned int for one-bit bitfield in sched_dl_entity

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

Re: [PATCH] sched: use unsigned int for one-bit bitfield in sched_dl_entity

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

Re: New sparse warnings from sched.h

Hi, On Tue, 14 Nov 2017 12:41:35 -0800 Matthew Wilcox <wi...@infradead.org> wrote: > commit 799ba82de01e7543f6b2042e1a739f3a20255f23 > Author: luca abeni <luca.ab...@santannapisa.it> > Date: Thu Sep 7 12:09:31 2017 +0200 > > sched/deadline: Use C bi

Re: New sparse warnings from sched.h

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

Re: [PATCH] sched/deadline: Don't use dubious signed bitfields

ed int" is the common practice for bitfields, I agree with the change. Reviewed-by: Luca Abeni <luca.ab...@santannapisa.it> Thanks, Luca > > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 0f897df

Re: [PATCH] sched/deadline: Don't use dubious signed bitfields

> 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 agree with

Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting

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

Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting

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

[tip:sched/core] sched/deadline: Use C bitfields for the state flags

Commit-ID: 799ba82de01e7543f6b2042e1a739f3a20255f23 Gitweb: https://git.kernel.org/tip/799ba82de01e7543f6b2042e1a739f3a20255f23 Author: luca abeni <luca.ab...@santannapisa.it> AuthorDate: Thu, 7 Sep 2017 12:09:31 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/deadline: Use C bitfields for the state flags

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

[tip:sched/core] sched/deadline: Fix switching to -deadline

Commit-ID: 295d6d5e373607729bcc8182c25afe964655714f Gitweb: https://git.kernel.org/tip/295d6d5e373607729bcc8182c25afe964655714f Author: Luca Abeni <luca.ab...@santannapisa.it> AuthorDate: Thu, 7 Sep 2017 12:09:29 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/deadline: Fix switching to -deadline

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

[tip:sched/core] sched/headers: Remove duplicate prototype of __dl_clear_params()

Commit-ID: e964d3501b64d6930aaa4dd18955a8cd086ccb92 Gitweb: https://git.kernel.org/tip/e964d3501b64d6930aaa4dd18955a8cd086ccb92 Author: luca abeni <luca.ab...@santannapisa.it> AuthorDate: Thu, 7 Sep 2017 12:09:28 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/headers: Remove duplicate prototype of __dl_clear_params()

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

[PATCH 4/4] sched/deadline: use C bitfields for the state flags

, "&" and "|"). Signed-off-by: luca abeni <luca.ab...@santannapisa.it> --- 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

[PATCH 4/4] sched/deadline: use C bitfields for the state flags

, "&" 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 2/4] sched/deadline: fix switching to -deadline

. This patch fixes the problem by initializing the task's parameters before enqueuing it. Signed-off-by: luca abeni <luca.ab...@santannapisa.it> Reviewed-by: Daniel Bristot de Oliveira <bris...@redhat.com> --- kernel/sched/deadline.c | 11 --- 1 file changed, 4 insertions(+), 7 deleti

[PATCH 2/4] sched/deadline: fix switching to -deadline

. This 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/sched

[PATCH 3/4] sched/deadline: rename __dl_clear() to __dl_sub()

From: Peter Zijlstra <pet...@infradead.org> __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) <pet...@infradead.org> Signed-off-by: luca abeni <luca.ab...@santannapisa.it>

[PATCH 3/4] sched/deadline: rename __dl_clear() to __dl_sub()

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

[PATCH 1/4] sched/sched.h: remove duplicate prototype of __dl_clear_params()

Signed-off-by: luca abeni <luca.ab...@santannapisa.it> --- 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 @@ exte

  1   2   3   4   5   6   7   8   >