On 04/02/19 13:07, Peter Zijlstra wrote:
> On Mon, Feb 04, 2019 at 01:02:36PM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 17, 2019 at 09:47:37AM +0100, Juri Lelli wrote:
> > > @@ -3233,11 +3233,11 @@ void cpuset_cpus_allowed(struct task_struct *tsk,
> >
On 04/02/19 12:55, Peter Zijlstra wrote:
> On Thu, Jan 17, 2019 at 09:47:37AM +0100, Juri Lelli wrote:
> > @@ -2366,7 +2366,7 @@ static int cpuset_common_seq_show(struct seq_file
> > *sf, void *v)
> > cpuset_filetype_t type = seq_cft(sf)->priv
On 18/01/19 17:46, Juri Lelli wrote:
> On 18/01/19 08:17, Tejun Heo wrote:
> > On Thu, Jan 17, 2019 at 09:47:34AM +0100, Juri Lelli wrote:
> > > Hi,
> > >
> > > v6 of a series of patches, originally authored by Mathieu, with the intent
> > > of f
On 18/01/19 08:17, Tejun Heo wrote:
> On Thu, Jan 17, 2019 at 09:47:34AM +0100, Juri Lelli wrote:
> > Hi,
> >
> > v6 of a series of patches, originally authored by Mathieu, with the intent
> > of fixing a long standing issue of SCHED_DEADLINE bandwidth accounting.
On 17/01/19 15:55, Rafael J. Wysocki wrote:
> On Thu, Jan 17, 2019 at 2:16 PM Juri Lelli wrote:
> >
> > On 11/01/19 10:47, Rafael J. Wysocki wrote:
> > > On Fri, Jan 11, 2019 at 10:18 AM Viresh Kumar
> > > wrote:
> > > >
> > > >
Hi,
On 18/01/19 10:34, Quentin Perret wrote:
> Hi Rafael,
>
> On Friday 18 Jan 2019 at 10:57:08 (+0100), Rafael J. Wysocki wrote:
> > On Fri, Jan 18, 2019 at 10:16 AM Quentin Perret
> > wrote:
> > >
> > > Hi Juri,
> > >
> > > On T
Hi,
On 10/01/19 11:05, Quentin Perret wrote:
> Add some documentation detailing the main design points of EAS, as well
> as a list of its dependencies.
>
> Parts of this documentation are taken from Morten Rasmussen's original
> EAS posting: https://lkml.org/lkml/2015/7/7/754
>
> Reviewed-by:
Hi,
On 10/01/19 11:05, Quentin Perret wrote:
> Introduce a documentation file summarizing the key design points and
> APIs of the newly introduced Energy Model framework.
>
> Signed-off-by: Quentin Perret
Looks good to me.
Reviewed-by: Juri Lelli
Best,
- Juri
On 11/01/19 10:47, Rafael J. Wysocki wrote:
> On Fri, Jan 11, 2019 at 10:18 AM Viresh Kumar wrote:
> >
> > Hi,
> >
> > This commit introduces the frequency constraint infrastructure, which
> > provides a generic interface for parts of the kernel to constraint the
> > working frequency range of a
From: Mathieu Poirier
Calls to task_rq_unlock() are done several times in function
__sched_setscheduler(). This is fine when only the rq lock needs to be
handled but not so much when other locks come into play.
This patch streamlines the release of the rq lock so that only one
location need to
,
- Juri
[1] https://lkml.org/lkml/2016/2/3/966
Juri Lelli (1):
cgroup/cpuset: make callback_lock raw
Mathieu Poirier (4):
sched/topology: Adding function partition_sched_domains_locked()
sched/core: Streamlining calls to task_rq_unlock()
sched/core: Prevent race condition between cpuset
of CPU bandwidth.
Grab callback_lock from core scheduler, so to prevent situations such as
the one described above from happening.
Signed-off-by: Mathieu Poirier
Signed-off-by: Juri Lelli
---
v5->v6: Added more descriptive comments about why callback_lock gives
the holder read-only acc
in
CPUsets and adding their current load to the root domain they are
associated with.
Signed-off-by: Mathieu Poirier
Signed-off-by: Juri Lelli
---
v5 -> v6: Since the list of tasks that belongs to each cgroup is lazily
built only the first time cgroups are mounted, to be able to
atomic context.
Signed-off-by: Juri Lelli
---
v5->v6: minor changes required to rebase on top of Waiman Long's cpuset
for cgroup v2 set.
---
kernel/cgroup/cpuset.c | 70 +-
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/kernel/cgr
From: Mathieu Poirier
Introducing function partition_sched_domains_locked() by taking
the mutex locking code out of the original function. That way
the work done by partition_sched_domains_locked() can be reused
without dropping the mutex lock.
No change of functionality is introduced by this
. More details are available from the summit
web page: http://retis.sssup.it/ospm-summit/#site
* https://goo.gl/maps/2pPXG2v7Lfp
.:: ORGANIZERS (in alphabetical order)
Luca Abeni (SSSA)
Patrick Bellasi (Arm)
Tommaso Cucinotta (SSSA)
Dietmar Eggemann (Arm)
Sudeep Holla (Arm)
Juri Lelli (Red Hat
Hi,
On 02/01/19 10:15, luca abeni wrote:
> 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
Signed-off-by: Juri Lelli
---
Got to scratch my head a bit while debugging a WARNING splat related to
the offlining of CPU0. Without being aware yet of this debug option it
wasn't immediately obvious why CPU0 was being offlined by the kernel.
Hope this makes sense and is acceptable. :-)
---
arch/
.
Signed-off-by: Juri Lelli
---
kernel/cgroup/cpuset.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index f0decd8165e7..f0822a730879 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -725,11 +725
Holding hotplug lock is not a requirement anymore for callers of sched_
init_domains after commit 6acce3ef8452 ("sched: Remove get_online_cpus()
usage").
Update the relative comment preceding init_sched_domains().
Signed-off-by: Juri Lelli
---
kernel/sched/topology.c | 5 ++---
1 fi
>
>
> Thanks Will for pointing this. I agree with you and like to be added as
> reviewer for this.
>
> Since arch_topology.c was mostly added for ARM/ARM64 and by Juri Lelli
> (who is no longer with ARM) and I did review the initial version, I would
> like to assume maintenance
>
>
> Thanks Will for pointing this. I agree with you and like to be added as
> reviewer for this.
>
> Since arch_topology.c was mostly added for ARM/ARM64 and by Juri Lelli
> (who is no longer with ARM) and I did review the initial version, I would
> like to assume maintenance
On 29/11/18 11:02, Daniel Lezcano wrote:
> On 29/11/2018 10:58, Juri Lelli wrote:
> > On 29/11/18 10:18, Daniel Lezcano wrote:
> >> On 29/11/2018 08:04, Juri Lelli wrote:
> >>
> >> [ ... ]
> >>
> >>>> With or without thi
On 29/11/18 11:02, Daniel Lezcano wrote:
> On 29/11/2018 10:58, Juri Lelli wrote:
> > On 29/11/18 10:18, Daniel Lezcano wrote:
> >> On 29/11/2018 08:04, Juri Lelli wrote:
> >>
> >> [ ... ]
> >>
> >>>> With or without thi
On 29/11/18 10:18, Daniel Lezcano wrote:
> On 29/11/2018 08:04, Juri Lelli wrote:
>
> [ ... ]
>
> >> With or without this patch, it is the case:
> >>
> >> task1 task2
> >> |
On 29/11/18 10:18, Daniel Lezcano wrote:
> On 29/11/2018 08:04, Juri Lelli wrote:
>
> [ ... ]
>
> >> With or without this patch, it is the case:
> >>
> >> task1 task2
> >> |
On 28/11/18 18:54, Daniel Lezcano wrote:
> On 28/11/2018 12:44, Juri Lelli wrote:
> > Hi Daniel,
> >
> > On 27/11/18 14:24, Daniel Lezcano wrote:
> >> The mutex protects a per_cpu variable access. The potential race can
> >> happen only when the cpufreq go
On 28/11/18 18:54, Daniel Lezcano wrote:
> On 28/11/2018 12:44, Juri Lelli wrote:
> > Hi Daniel,
> >
> > On 27/11/18 14:24, Daniel Lezcano wrote:
> >> The mutex protects a per_cpu variable access. The potential race can
> >> happen only when the cpufreq go
Hi Daniel,
On 27/11/18 14:24, Daniel Lezcano wrote:
> The mutex protects a per_cpu variable access. The potential race can
> happen only when the cpufreq governor module is loaded and at the same
> time the cpu capacity is changed in the sysfs.
>
> There is no real interest of using a mutex to
Hi Daniel,
On 27/11/18 14:24, Daniel Lezcano wrote:
> The mutex protects a per_cpu variable access. The potential race can
> happen only when the cpufreq governor module is loaded and at the same
> time the cpu capacity is changed in the sysfs.
>
> There is no real interest of using a mutex to
ssues.
> >
> > If user-space starts writing the value to influence the scheduler, then
> > it makes it difficult for kernel to change the way it uses the
> > cpu_capacity in future.
> >
> > Sorry if there's valid usecase and I am just making noise here.
&
ssues.
> >
> > If user-space starts writing the value to influence the scheduler, then
> > it makes it difficult for kernel to change the way it uses the
> > cpu_capacity in future.
> >
> > Sorry if there's valid usecase and I am just making noise here.
&
On 19/11/18 14:43, Juri Lelli wrote:
> On 19/11/18 13:52, Peter Zijlstra wrote:
> > On Mon, Nov 19, 2018 at 01:07:18PM +0100, luca abeni wrote:
> >
> > > > On Sun, 18 Nov 2018, syzbot wrote:
> >
> > > > > WARNING: CPU: 1 PID: 6351 at kernel/sched
On 19/11/18 14:43, Juri Lelli wrote:
> On 19/11/18 13:52, Peter Zijlstra wrote:
> > On Mon, Nov 19, 2018 at 01:07:18PM +0100, luca abeni wrote:
> >
> > > > On Sun, 18 Nov 2018, syzbot wrote:
> >
> > > > > WARNING: CPU: 1 PID: 6351 at kernel/sched
On 19/11/18 13:52, Peter Zijlstra wrote:
> On Mon, Nov 19, 2018 at 01:07:18PM +0100, luca abeni wrote:
>
> > > On Sun, 18 Nov 2018, syzbot wrote:
>
> > > > WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628
> > > > enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
> >
> > Here,
On 19/11/18 13:52, Peter Zijlstra wrote:
> On Mon, Nov 19, 2018 at 01:07:18PM +0100, luca abeni wrote:
>
> > > On Sun, 18 Nov 2018, syzbot wrote:
>
> > > > WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628
> > > > enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
> >
> > Here,
On 08/11/18 14:11, Waiman Long wrote:
> On 11/07/2018 11:38 AM, Juri Lelli wrote:
> > Hi,
> >
> > On 07/11/18 07:53, Tejun Heo wrote:
> >> Hello,
> >>
> >> On Tue, Sep 25, 2018 at 04:34:16PM +0200, Juri Lelli wrote:
> >>> It would be
On 08/11/18 14:11, Waiman Long wrote:
> On 11/07/2018 11:38 AM, Juri Lelli wrote:
> > Hi,
> >
> > On 07/11/18 07:53, Tejun Heo wrote:
> >> Hello,
> >>
> >> On Tue, Sep 25, 2018 at 04:34:16PM +0200, Juri Lelli wrote:
> >>> It would be
Hi,
On 08/11/18 10:49, Waiman Long wrote:
> On 10/04/2018 05:04 AM, Juri Lelli wrote:
[...]
> > +/**
> > + * cpuset_read_only_lock - Grab the callback_lock from cpuset subsystem.
> > + *
> > + * Description: As described in full details the comment above cpuset_mute
Hi,
On 08/11/18 10:49, Waiman Long wrote:
> On 10/04/2018 05:04 AM, Juri Lelli wrote:
[...]
> > +/**
> > + * cpuset_read_only_lock - Grab the callback_lock from cpuset subsystem.
> > + *
> > + * Description: As described in full details the comment above cpuset_mute
On 07/11/18 17:38, Juri Lelli wrote:
> Hi,
>
> On 07/11/18 07:53, Tejun Heo wrote:
> > Hello,
> >
> > On Tue, Sep 25, 2018 at 04:34:16PM +0200, Juri Lelli wrote:
> > > It would be great if you could please have a look at the proposed change
> >
On 07/11/18 17:38, Juri Lelli wrote:
> Hi,
>
> On 07/11/18 07:53, Tejun Heo wrote:
> > Hello,
> >
> > On Tue, Sep 25, 2018 at 04:34:16PM +0200, Juri Lelli wrote:
> > > It would be great if you could please have a look at the proposed change
> >
Commit-ID: e6a2d72c10405b30ddba5af2e44a9d3d925a56d3
Gitweb: https://git.kernel.org/tip/e6a2d72c10405b30ddba5af2e44a9d3d925a56d3
Author: Juri Lelli
AuthorDate: Wed, 7 Nov 2018 12:10:32 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 8 Nov 2018 07:43:35 +0100
posix-cpu-timers: Remove
Commit-ID: e6a2d72c10405b30ddba5af2e44a9d3d925a56d3
Gitweb: https://git.kernel.org/tip/e6a2d72c10405b30ddba5af2e44a9d3d925a56d3
Author: Juri Lelli
AuthorDate: Wed, 7 Nov 2018 12:10:32 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 8 Nov 2018 07:43:35 +0100
posix-cpu-timers: Remove
Hi,
On 07/11/18 07:53, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 25, 2018 at 04:34:16PM +0200, Juri Lelli wrote:
> > It would be great if you could please have a look at the proposed change
> > below (and the rest of the set of course :-).
>
> Yeah, looks good to m
Hi,
On 07/11/18 07:53, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 25, 2018 at 04:34:16PM +0200, Juri Lelli wrote:
> > It would be great if you could please have a look at the proposed change
> > below (and the rest of the set of course :-).
>
> Yeah, looks good to m
sched/deadline: Implement "runtime overrun signal"
support")
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Luca Abeni
Cc: Claudio Scordino
Cc: Mathieu Poirier
---
kernel/time/posix-cpu-timers.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/k
sched/deadline: Implement "runtime overrun signal"
support")
Signed-off-by: Juri Lelli
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Luca Abeni
Cc: Claudio Scordino
Cc: Mathieu Poirier
---
kernel/time/posix-cpu-timers.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/k
Hi,
Ping.
Thanks,
- Juri
On 25/09/18 16:34, Juri Lelli wrote:
> Hi Li Zefan and Tejun Heo,
>
> It would be great if you could please have a look at the proposed change
> below (and the rest of the set of course :-).
>
> Another bit that I'd be more comfortable after
Hi,
Ping.
Thanks,
- Juri
On 25/09/18 16:34, Juri Lelli wrote:
> Hi Li Zefan and Tejun Heo,
>
> It would be great if you could please have a look at the proposed change
> below (and the rest of the set of course :-).
>
> Another bit that I'd be more comfortable after
On 30/10/18 12:12, Juri Lelli wrote:
> On 30/10/18 11:45, Peter Zijlstra wrote:
>
> [...]
>
> > Hurm.. right. We knew of this issue back when we did it.
> > I suppose now it hurts and we need to figure something out.
> >
> > By virtue of being a real-t
On 30/10/18 12:12, Juri Lelli wrote:
> On 30/10/18 11:45, Peter Zijlstra wrote:
>
> [...]
>
> > Hurm.. right. We knew of this issue back when we did it.
> > I suppose now it hurts and we need to figure something out.
> >
> > By virtue of being a real-t
On 02/11/18 11:00, Daniel Bristot de Oliveira wrote:
> On 11/1/18 6:55 AM, Juri Lelli wrote:
> >> I meant, I am not against the/a fix, i just think that... it is more
> >> complicated
> >> that it seems.
> >>
> >> For example: Let's as
On 02/11/18 11:00, Daniel Bristot de Oliveira wrote:
> On 11/1/18 6:55 AM, Juri Lelli wrote:
> >> I meant, I am not against the/a fix, i just think that... it is more
> >> complicated
> >> that it seems.
> >>
> >> For example: Let's as
On 31/10/18 18:58, Daniel Bristot de Oliveira wrote:
> On 10/31/18 5:40 PM, Juri Lelli wrote:
> > On 31/10/18 17:18, Daniel Bristot de Oliveira wrote:
> >> On 10/30/18 12:08 PM, luca abeni wrote:
> >>> Hi Peter,
> >>>
> >>> On Tue,
On 31/10/18 18:58, Daniel Bristot de Oliveira wrote:
> On 10/31/18 5:40 PM, Juri Lelli wrote:
> > On 31/10/18 17:18, Daniel Bristot de Oliveira wrote:
> >> On 10/30/18 12:08 PM, luca abeni wrote:
> >>> Hi Peter,
> >>>
> >>> On Tue,
On 31/10/18 17:18, Daniel Bristot de Oliveira wrote:
> On 10/30/18 12:08 PM, luca abeni wrote:
> > 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
On 31/10/18 17:18, Daniel Bristot de Oliveira wrote:
> On 10/30/18 12:08 PM, luca abeni wrote:
> > 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
On 30/10/18 11:45, Peter Zijlstra wrote:
[...]
> Hurm.. right. We knew of this issue back when we did it.
> I suppose now it hurts and we need to figure something out.
>
> By virtue of being a real-time class, we do indeed need to have deadline
> on the wall-clock. But if we then don't account
On 30/10/18 11:45, Peter Zijlstra wrote:
[...]
> Hurm.. right. We knew of this issue back when we did it.
> I suppose now it hurts and we need to figure something out.
>
> By virtue of being a real-time class, we do indeed need to have deadline
> on the wall-clock. But if we then don't account
On 27/10/18 12:16, Dmitry Vyukov wrote:
> On Wed, Oct 24, 2018 at 1:03 PM, Juri Lelli wrote:
> >
> > On 19/10/18 22:50, luca abeni wrote:
> > > On Fri, 19 Oct 2018 13:39:42 +0200
> > > Peter Zijlstra wrote:
> > >
> > > > On Thu, Oct 18, 2018
On 27/10/18 12:16, Dmitry Vyukov wrote:
> On Wed, Oct 24, 2018 at 1:03 PM, Juri Lelli wrote:
> >
> > On 19/10/18 22:50, luca abeni wrote:
> > > On Fri, 19 Oct 2018 13:39:42 +0200
> > > Peter Zijlstra wrote:
> > >
> > > > On Thu, Oct 18, 2018
On 19/10/18 22:50, luca abeni wrote:
> 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,
On 19/10/18 22:50, luca abeni wrote:
> 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,
On 18/10/18 13:08, luca abeni wrote:
> 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
> > &
On 18/10/18 13:08, luca abeni wrote:
> 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
> > &
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 {
> > .size = 0,
> > .policy = 6,
> > .flags = 0,
> > .nice = 0,
> > .p
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 {
> > .size = 0,
> > .policy = 6,
> > .flags = 0,
> > .nice = 0,
> > .p
On 18/10/18 11:48, Peter Zijlstra wrote:
> On Thu, Oct 18, 2018 at 10:28:38AM +0200, Juri Lelli wrote:
>
> > Another side problem seems also to be that with such tiny parameters we
> > spend lot of time in the while (dl_se->runtime <= 0) loop of replenish_dl_
> >
On 18/10/18 11:48, Peter Zijlstra wrote:
> On Thu, Oct 18, 2018 at 10:28:38AM +0200, Juri Lelli wrote:
>
> > Another side problem seems also to be that with such tiny parameters we
> > spend lot of time in the while (dl_se->runtime <= 0) loop of replenish_dl_
> >
On 16/10/18 16:03, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > It does reproduce here but with a kworker stall. Looking at the reproducer:
> >
> > *(uint32_t*)0x2000 = 0;
> > *(uint32_t*)0x2004 = 6;
> > *(uint64_t*)0x2008 = 0;
> >
On 16/10/18 16:03, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > It does reproduce here but with a kworker stall. Looking at the reproducer:
> >
> > *(uint32_t*)0x2000 = 0;
> > *(uint32_t*)0x2004 = 6;
> > *(uint64_t*)0x2008 = 0;
> >
On 16/10/18 16:45, Thomas Gleixner wrote:
> On Tue, 16 Oct 2018, Juri Lelli wrote:
> > On 16/10/18 16:03, Peter Zijlstra wrote:
> > > On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > > > It does reproduce here but with a kworker stall. Look
On 16/10/18 16:45, Thomas Gleixner wrote:
> On Tue, 16 Oct 2018, Juri Lelli wrote:
> > On 16/10/18 16:03, Peter Zijlstra wrote:
> > > On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > > > It does reproduce here but with a kworker stall. Look
On 16/10/18 16:03, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > It does reproduce here but with a kworker stall. Looking at the reproducer:
> >
> > *(uint32_t*)0x2000 = 0;
> > *(uint32_t*)0x2004 = 6;
> > *(uint64_t*)0x2008 = 0;
> >
On 16/10/18 16:03, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > It does reproduce here but with a kworker stall. Looking at the reproducer:
> >
> > *(uint32_t*)0x2000 = 0;
> > *(uint32_t*)0x2004 = 6;
> > *(uint64_t*)0x2008 = 0;
> >
On 16/10/18 14:36, Quentin Perret wrote:
> Hi,
>
> On Tuesday 16 Oct 2018 at 14:50:58 (+0200), Juri Lelli wrote:
> > Hi,
> >
> > On 16/10/18 11:15, Quentin Perret wrote:
> >
> > [...]
> >
> > > diff --git a/kernel/sysctl.c b/kernel/
On 16/10/18 14:36, Quentin Perret wrote:
> Hi,
>
> On Tuesday 16 Oct 2018 at 14:50:58 (+0200), Juri Lelli wrote:
> > Hi,
> >
> > On 16/10/18 11:15, Quentin Perret wrote:
> >
> > [...]
> >
> > > diff --git a/kernel/sysctl.c b/kernel/
Hi,
On 16/10/18 11:15, Quentin Perret wrote:
[...]
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index cc02050fd0c4..481309a11174 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -466,6 +466,17 @@ static struct ctl_table kern_table[] = {
> .extra1 = ,
>
Hi,
On 16/10/18 11:15, Quentin Perret wrote:
[...]
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index cc02050fd0c4..481309a11174 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -466,6 +466,17 @@ static struct ctl_table kern_table[] = {
> .extra1 = ,
>
On 12/10/18 09:22, luca abeni wrote:
> 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);
> > > > > + /*
> > > > > +
On 12/10/18 09:22, luca abeni wrote:
> 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);
> > > > > + /*
> > > > > +
On 11/10/18 14:53, Peter Zijlstra wrote:
[...]
> I think it was the safe and simple choice; note that we're not migrating
> just a single @p, but a whole chain of @p. rq->curr must not be any of the
> possible @p's. rq->idle, is per definition not one of the @p's.
>
> Does that make sense?
It
On 11/10/18 14:53, Peter Zijlstra wrote:
[...]
> I think it was the safe and simple choice; note that we're not migrating
> just a single @p, but a whole chain of @p. rq->curr must not be any of the
> possible @p's. rq->idle, is per definition not one of the @p's.
>
> Does that make sense?
It
Hi Luca,
On 10/10/18 13:10, luca abeni wrote:
> 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
Hi Luca,
On 10/10/18 13:10, luca abeni wrote:
> 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
On 10/10/18 15:08, Vincent Guittot wrote:
> On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
> >
> > On 10/10/18 14:34, Vincent Guittot wrote:
> > > Hi Juri,
> > >
> > > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
On 10/10/18 15:08, Vincent Guittot wrote:
> On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
> >
> > On 10/10/18 14:34, Vincent Guittot wrote:
> > > Hi Juri,
> > >
> > > On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> > >
On 10/10/18 14:34, Vincent Guittot wrote:
> Hi Juri,
>
> On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> >
> > On 10/10/18 14:04, Vincent Guittot wrote:
> >
> > [...]
> >
> > > The problem was the same with RT, the cfs utilization was lower
On 10/10/18 14:34, Vincent Guittot wrote:
> Hi Juri,
>
> On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
> >
> > On 10/10/18 14:04, Vincent Guittot wrote:
> >
> > [...]
> >
> > > The problem was the same with RT, the cfs utilization was lower
On 10/10/18 13:56, Henrik Austad wrote:
> On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> > Hi all,
>
> Hi, nice series, I have a lot of details to grok, but I like the idea of PE
>
> > Proxy Execution (also goes under several other names) isn't a new
On 10/10/18 13:56, Henrik Austad wrote:
> On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> > Hi all,
>
> Hi, nice series, I have a lot of details to grok, but I like the idea of PE
>
> > Proxy Execution (also goes under several other names) isn't a new
On 10/10/18 13:23, Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 01:16:29PM +0200, luca abeni wrote:
> > 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
On 10/10/18 13:23, Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 01:16:29PM +0200, luca abeni wrote:
> > 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
On 10/10/18 14:04, Vincent Guittot wrote:
[...]
> The problem was the same with RT, the cfs utilization was lower than
> reality because RT steals soem cycle to CFS
> So schedutil was selecting a lower frequency when cfs was running
> whereas the CPU was fully used.
> The same can happen with
On 10/10/18 14:04, Vincent Guittot wrote:
[...]
> The problem was the same with RT, the cfs utilization was lower than
> reality because RT steals soem cycle to CFS
> So schedutil was selecting a lower frequency when cfs was running
> whereas the CPU was fully used.
> The same can happen with
On 10/10/18 12:43, luca abeni wrote:
> 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
On 10/10/18 12:43, luca abeni wrote:
> 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
On 09/10/18 13:56, Daniel Bristot de Oliveira wrote:
> On 10/9/18 12:51 PM, Sebastian Andrzej Siewior wrote:
> >> The main concerns I have with the current approach is that, being based
> >> on mutex.c, it's both
> >>
> >> - not linked with futexes
> >> - not involving "legacy" priority
On 09/10/18 13:56, Daniel Bristot de Oliveira wrote:
> On 10/9/18 12:51 PM, Sebastian Andrzej Siewior wrote:
> >> The main concerns I have with the current approach is that, being based
> >> on mutex.c, it's both
> >>
> >> - not linked with futexes
> >> - not involving "legacy" priority
201 - 300 of 2448 matches
Mail list logo
