Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/02/18 08:33, Mathieu Poirier wrote: > On 14 February 2018 at 04:27, Juri Lelli <juri.le...@redhat.com> wrote: > > On 14/02/18 11:49, Juri Lelli wrote: > >> On 14/02/18 11:36, Juri Lelli wrote: > >> > Hi Mathieu, > >> >

Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/02/18 08:33, Mathieu Poirier wrote: > On 14 February 2018 at 04:27, Juri Lelli wrote: > > On 14/02/18 11:49, Juri Lelli wrote: > >> On 14/02/18 11:36, Juri Lelli wrote: > >> > Hi Mathieu, > >> > > >> > On 13/02/18 13:32, Mathieu Poir

Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/02/18 11:49, Juri Lelli wrote: > On 14/02/18 11:36, Juri Lelli wrote: > > Hi Mathieu, > > > > On 13/02/18 13:32, Mathieu Poirier wrote: > > > No synchronisation mechanism exist between the cpuset subsystem and calls > > > to function __sched_setschedu

Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/02/18 11:49, Juri Lelli wrote: > On 14/02/18 11:36, Juri Lelli wrote: > > Hi Mathieu, > > > > On 13/02/18 13:32, Mathieu Poirier wrote: > > > No synchronisation mechanism exist between the cpuset subsystem and calls > > > to function __sched_setschedu

[tip:locking/core] Documentation/locking/lockdep: Add section about available annotations

Commit-ID: a1ea544fe0911492b9f8d101bcbf46cc8c47fbc5 Gitweb: https://git.kernel.org/tip/a1ea544fe0911492b9f8d101bcbf46cc8c47fbc5 Author: Juri Lelli <juri.le...@redhat.com> AuthorDate: Tue, 13 Feb 2018 19:55:19 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 14

[tip:locking/core] Documentation/locking/lockdep: Add section about available annotations

Commit-ID: a1ea544fe0911492b9f8d101bcbf46cc8c47fbc5 Gitweb: https://git.kernel.org/tip/a1ea544fe0911492b9f8d101bcbf46cc8c47fbc5 Author: Juri Lelli AuthorDate: Tue, 13 Feb 2018 19:55:19 +0100 Committer: Ingo Molnar CommitDate: Wed, 14 Feb 2018 12:01:22 +0100 Documentation/locking

[tip:locking/core] Documentation/locking/lockdep: Update info about states

Commit-ID: e5684bbfc3f03480d6ba2150f133630fb510d3eb Gitweb: https://git.kernel.org/tip/e5684bbfc3f03480d6ba2150f133630fb510d3eb Author: Juri Lelli <juri.le...@redhat.com> AuthorDate: Tue, 13 Feb 2018 19:55:18 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 14

[tip:locking/core] Documentation/locking/lockdep: Update info about states

Commit-ID: e5684bbfc3f03480d6ba2150f133630fb510d3eb Gitweb: https://git.kernel.org/tip/e5684bbfc3f03480d6ba2150f133630fb510d3eb Author: Juri Lelli AuthorDate: Tue, 13 Feb 2018 19:55:18 +0100 Committer: Ingo Molnar CommitDate: Wed, 14 Feb 2018 12:01:22 +0100 Documentation/locking

Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/02/18 11:36, Juri Lelli wrote: > Hi Mathieu, > > On 13/02/18 13:32, Mathieu Poirier wrote: > > No synchronisation mechanism exist between the cpuset subsystem and calls > > to function __sched_setscheduler(). As such it is possible that new root > > domains are

Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/02/18 11:36, Juri Lelli wrote: > Hi Mathieu, > > On 13/02/18 13:32, Mathieu Poirier wrote: > > No synchronisation mechanism exist between the cpuset subsystem and calls > > to function __sched_setscheduler(). As such it is possible that new root > > domains are

Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

Hi Mathieu, On 13/02/18 13:32, Mathieu Poirier wrote: > No synchronisation mechanism exist between the cpuset subsystem and calls > to function __sched_setscheduler(). As such it is possible that new root > domains are created on the cpuset side while a deadline acceptance test > is carried out

Re: [PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

Hi Mathieu, On 13/02/18 13:32, Mathieu Poirier wrote: > No synchronisation mechanism exist between the cpuset subsystem and calls > to function __sched_setscheduler(). As such it is possible that new root > domains are created on the cpuset side while a deadline acceptance test > is carried out

[PATCH 0/2] Update lockdep doc and add section about annotations

is pretty new and maybe got unnoticed outside of the scheduler?). Best, - Juri Juri Lelli (2): Documentation/locking/lockdep: update info about states Documentation/locking/lockdep: Add section about available annotations Documentation/locking/lockdep-design.txt | 51

[PATCH 0/2] Update lockdep doc and add section about annotations

is pretty new and maybe got unnoticed outside of the scheduler?). Best, - Juri Juri Lelli (2): Documentation/locking/lockdep: update info about states Documentation/locking/lockdep: Add section about available annotations Documentation/locking/lockdep-design.txt | 51

[RFC PATCH 2/2] Documentation/locking/lockdep: Add section about available annotations

Add section about annotations that can be used to perform additional runtime checking of locking correctness: assert that certain locks are held and prevent accidental unlocking. Signed-off-by: Juri Lelli <juri.le...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ing

[RFC PATCH 2/2] Documentation/locking/lockdep: Add section about available annotations

Add section about annotations that can be used to perform additional runtime checking of locking correctness: assert that certain locks are held and prevent accidental unlocking. Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jonathan Corbet Cc: linux-kernel@vger.kernel.org

[PATCH 1/2] Documentation/locking/lockdep: update info about states

Commit d92a8cfcb37e ("locking/lockdep: Rework FS_RECLAIM annotation") removed reclaim_fs lockdep STATE. Reflect the change in documentation. While we are at it, also clarify formula to calculate number of state bits. Signed-off-by: Juri Lelli <juri.le...@redhat.com> Cc: Pet

[PATCH 1/2] Documentation/locking/lockdep: update info about states

Commit d92a8cfcb37e ("locking/lockdep: Rework FS_RECLAIM annotation") removed reclaim_fs lockdep STATE. Reflect the change in documentation. While we are at it, also clarify formula to calculate number of state bits. Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc

Re: [RFC PATCH 1/3] sched/deadline: merge dl_bw into dl_bandwidth

On 12/02/18 13:02, Steven Rostedt wrote: > On Mon, 12 Feb 2018 18:43:12 +0100 > Juri Lelli <juri.le...@redhat.com> wrote: > > > However, this surely needs to be fixed here. It's tracking the sum of > > all tasks' (across CPUs) bandwidth admitted on the system, so

Re: [RFC PATCH 1/3] sched/deadline: merge dl_bw into dl_bandwidth

On 12/02/18 13:02, Steven Rostedt wrote: > On Mon, 12 Feb 2018 18:43:12 +0100 > Juri Lelli wrote: > > > However, this surely needs to be fixed here. It's tracking the sum of > > all tasks' (across CPUs) bandwidth admitted on the system, so that's why > > it's called dl

Re: [RFC PATCH 1/3] sched/deadline: merge dl_bw into dl_bandwidth

On 12/02/18 12:34, Steven Rostedt wrote: > On Mon, 12 Feb 2018 14:40:28 +0100 > Juri Lelli <juri.le...@redhat.com> wrote: > > > + * - dl_bw (< 100%) is the bandwidth of the system (domain) on each CPU; > > + * - dl_total_bw array contains the currently allocated

Re: [RFC PATCH 1/3] sched/deadline: merge dl_bw into dl_bandwidth

On 12/02/18 12:34, Steven Rostedt wrote: > On Mon, 12 Feb 2018 14:40:28 +0100 > Juri Lelli wrote: > > > + * - dl_bw (< 100%) is the bandwidth of the system (domain) on each CPU; > > + * - dl_total_bw array contains the currently allocated bandwidth on the > > + *

Re: [RFC PATCH 2/3] sched/deadline: add task groups bandwidth management support

Hi, On 12/02/18 08:47, Tejun Heo wrote: > Hello, > > On Mon, Feb 12, 2018 at 02:40:29PM +0100, Juri Lelli wrote: > > - implementation _is not_ hierarchical: only single/plain DEADLINE entities > >can be handled, and they get scheduled at root rq level > > Thi

Re: [RFC PATCH 2/3] sched/deadline: add task groups bandwidth management support

Hi, On 12/02/18 08:47, Tejun Heo wrote: > Hello, > > On Mon, Feb 12, 2018 at 02:40:29PM +0100, Juri Lelli wrote: > > - implementation _is not_ hierarchical: only single/plain DEADLINE entities > >can be handled, and they get scheduled at root rq level > > Thi

[RFC PATCH 1/3] sched/deadline: merge dl_bw into dl_bandwidth

rt_bandwidth). Signed-off-by: Juri Lelli <juri.le...@redhat.com> Cc: Ingo Molnar <mi...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Luca Abeni <luca.ab...@santannapisa.it> Cc: linux-kernel@vger.kernel.org --- kernel/sched/core.c | 2 +- kern

[RFC PATCH 1/3] sched/deadline: merge dl_bw into dl_bandwidth

rt_bandwidth). Signed-off-by: Juri Lelli Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Luca Abeni Cc: linux-kernel@vger.kernel.org --- kernel/sched/core.c | 2 +- kernel/sched/deadline.c | 84 +++-- kernel/sched/debug.c| 6 ++-- kernel/sched/sched.h

[RFC PATCH 3/3] Documentation/scheduler/sched-deadline: add info about cgroup support

Add documentation for SCHED_DEADLINE cgroup support (CONFIG_DEADLINE_ GROUP_SCHED config option). Signed-off-by: Juri Lelli <juri.le...@redhat.com> Cc: Ingo Molnar <mi...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Tejun Heo <t...@kernel.org> Cc: Jonathan Co

[RFC PATCH 3/3] Documentation/scheduler/sched-deadline: add info about cgroup support

Add documentation for SCHED_DEADLINE cgroup support (CONFIG_DEADLINE_ GROUP_SCHED config option). Signed-off-by: Juri Lelli Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Tejun Heo Cc: Jonathan Corbet Cc: Luca Abeni Cc: linux-kernel@vger.kernel.org Cc: linux-...@vger.kernel.org --- Documentation

[RFC PATCH 2/3] sched/deadline: add task groups bandwidth management support

(rt_runtime_us/rt_period_us) # cpu.dl_total_bw : current total (across CPUs) amount of bandwidth allocated by the group (sum of tasks bandwidth) - father/children/siblings rules are the same as for RT Signed-off-by: Juri Lelli <juri.le...@redhat.com> Cc: Ingo

[RFC PATCH 0/3] SCHED_DEADLINE cgroups support

://lkml.org/lkml/2010/2/28/119 [2] https://lwn.net/Articles/718645/ Juri Lelli (3): sched/deadline: merge dl_bw into dl_bandwidth sched/deadline: add task groups bandwidth management support Documentation/scheduler/sched-deadline: add info about cgroup support Documentation/scheduler/sched

[RFC PATCH 2/3] sched/deadline: add task groups bandwidth management support

(rt_runtime_us/rt_period_us) # cpu.dl_total_bw : current total (across CPUs) amount of bandwidth allocated by the group (sum of tasks bandwidth) - father/children/siblings rules are the same as for RT Signed-off-by: Juri Lelli Cc: Ingo Molnar Cc: Peter Zijlstra Cc

[RFC PATCH 0/3] SCHED_DEADLINE cgroups support

://lkml.org/lkml/2010/2/28/119 [2] https://lwn.net/Articles/718645/ Juri Lelli (3): sched/deadline: merge dl_bw into dl_bandwidth sched/deadline: add task groups bandwidth management support Documentation/scheduler/sched-deadline: add info about cgroup support Documentation/scheduler/sched

[tip:locking/urgent] Documentation/locking/mutex-design: Update to reflect latest changes

Commit-ID: 79e902382637a2f421b7f295dcf9934d80d84d7d Gitweb: https://git.kernel.org/tip/79e902382637a2f421b7f295dcf9934d80d84d7d Author: Juri Lelli <juri.le...@redhat.com> AuthorDate: Fri, 9 Feb 2018 17:01:14 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun, 11

[tip:locking/urgent] Documentation/locking/mutex-design: Update to reflect latest changes

Commit-ID: 79e902382637a2f421b7f295dcf9934d80d84d7d Gitweb: https://git.kernel.org/tip/79e902382637a2f421b7f295dcf9934d80d84d7d Author: Juri Lelli AuthorDate: Fri, 9 Feb 2018 17:01:14 +0100 Committer: Ingo Molnar CommitDate: Sun, 11 Feb 2018 12:28:58 +0100 Documentation/locking/mutex

[PATCH] Documentation/locking/mutex-design: update to reflect latest changes

Commit 3ca0ff571b09 ("locking/mutex: Rework mutex::owner") reworked the basic mutex implementation to deal with several problems. Documentation was however left unchanged and became stale. Update mutex-design.txt to reflect changes introduced by the above commit. Signed-off-by:

[PATCH] Documentation/locking/mutex-design: update to reflect latest changes

Commit 3ca0ff571b09 ("locking/mutex: Rework mutex::owner") reworked the basic mutex implementation to deal with several problems. Documentation was however left unchanged and became stale. Update mutex-design.txt to reflect changes introduced by the above commit. Signed-off-by: Juri

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 13:56, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 1:52 PM, Juri Lelli <juri.le...@redhat.com> wrote: > > On 09/02/18 13:08, Rafael J. Wysocki wrote: > >> On Fri, Feb 9, 2018 at 12:51 PM, Juri Lelli <juri.le...@redhat.com> wrote: [...] > >

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 13:56, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 1:52 PM, Juri Lelli wrote: > > On 09/02/18 13:08, Rafael J. Wysocki wrote: > >> On Fri, Feb 9, 2018 at 12:51 PM, Juri Lelli wrote: [...] > >> > My impression is that rate limit helps

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 13:08, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 12:51 PM, Juri Lelli <juri.le...@redhat.com> wrote: > > On 09/02/18 12:37, Rafael J. Wysocki wrote: > >> On Fri, Feb 9, 2018 at 12:26 PM, Juri Lelli <juri.le...@redhat.com> wrote: > >> >

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 13:08, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 12:51 PM, Juri Lelli wrote: > > On 09/02/18 12:37, Rafael J. Wysocki wrote: > >> On Fri, Feb 9, 2018 at 12:26 PM, Juri Lelli wrote: > >> > On 09/02/18 12:04, Rafael J. Wysocki wrote: > >

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 12:37, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 12:26 PM, Juri Lelli <juri.le...@redhat.com> wrote: > > On 09/02/18 12:04, Rafael J. Wysocki wrote: > >> On Fri, Feb 9, 2018 at 11:53 AM, Juri Lelli <juri.le...@redhat.com> wrote: > >>

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 12:37, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 12:26 PM, Juri Lelli wrote: > > On 09/02/18 12:04, Rafael J. Wysocki wrote: > >> On Fri, Feb 9, 2018 at 11:53 AM, Juri Lelli wrote: > >> > Hi, > >> > > >> > On 09/0

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 12:04, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 11:53 AM, Juri Lelli <juri.le...@redhat.com> wrote: > > Hi, > > > > On 09/02/18 11:36, Rafael J. Wysocki wrote: > >> On Friday, February 9, 2018 9:02:34 AM CET Claudio Scordino wrote: > >

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On 09/02/18 12:04, Rafael J. Wysocki wrote: > On Fri, Feb 9, 2018 at 11:53 AM, Juri Lelli wrote: > > Hi, > > > > On 09/02/18 11:36, Rafael J. Wysocki wrote: > >> On Friday, February 9, 2018 9:02:34 AM CET Claudio Scordino wrote: > >> > Hi Viresh, > >

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

Hi, On 09/02/18 11:36, Rafael J. Wysocki wrote: > On Friday, February 9, 2018 9:02:34 AM CET Claudio Scordino wrote: > > Hi Viresh, > > > > Il 09/02/2018 04:51, Viresh Kumar ha scritto: > > > On 08-02-18, 18:01, Claudio Scordino wrote: > > >> When the SCHED_DEADLINE scheduling class increases

Re: [PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

Hi, On 09/02/18 11:36, Rafael J. Wysocki wrote: > On Friday, February 9, 2018 9:02:34 AM CET Claudio Scordino wrote: > > Hi Viresh, > > > > Il 09/02/2018 04:51, Viresh Kumar ha scritto: > > > On 08-02-18, 18:01, Claudio Scordino wrote: > > >> When the SCHED_DEADLINE scheduling class increases

Re: [PATCH V2 1/7] sched/topology: Adding function partition_sched_domains_locked()

On 05/02/18 11:11, Mathieu Poirier wrote: > On 2 February 2018 at 03:19, Juri Lelli <juri.le...@redhat.com> wrote: > > Hi Mathieu, > > > > On 01/02/18 09:51, Mathieu Poirier wrote: > >> Introducing function partition_sched_domains_locked() by taking > >&g

Re: [PATCH V2 1/7] sched/topology: Adding function partition_sched_domains_locked()

On 05/02/18 11:11, Mathieu Poirier wrote: > On 2 February 2018 at 03:19, Juri Lelli wrote: > > Hi Mathieu, > > > > On 01/02/18 09:51, Mathieu Poirier wrote: > >> Introducing function partition_sched_domains_locked() by taking > >> the mutex locking code

Re: [PATCH] sched/deadline: Make update_curr_dl() more accurate

lt;wen.yan...@zte.com.cn> > Reviewed-by: Jiang Biao <jiang.bi...@zte.com.cn> > Suggested-by: Peter Zijlstra <pet...@infradead.org> Acked-by: Juri Lelli <juri.le...@redhat.com> Thanks! - Juri

Re: [PATCH] sched/deadline: Make update_curr_dl() more accurate

> Reviewed-by: Jiang Biao > Suggested-by: Peter Zijlstra Acked-by: Juri Lelli Thanks! - Juri

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

Hi Steve, On 03/02/18 16:17, Steven Rostedt wrote: > On Sat, 3 Feb 2018 12:52:08 -0800 > Alexei Starovoitov wrote: > > > It's a user space job. > > BTW, I asked around at DevConf.cz, and nobody I talked with (besides > Arnaldo), have used eBPF. The "path to hello

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

Hi Steve, On 03/02/18 16:17, Steven Rostedt wrote: > On Sat, 3 Feb 2018 12:52:08 -0800 > Alexei Starovoitov wrote: > > > It's a user space job. > > BTW, I asked around at DevConf.cz, and nobody I talked with (besides > Arnaldo), have used eBPF. The "path to hello world" is quite high. This >

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

Hi Steve, On 02/02/18 18:04, Steven Rostedt wrote: > > At Kernel Summit back in October, we tried to bring up trace markers, which > would be nops within the kernel proper, that would allow modules to hook > arbitrary trace events to them. The reaction to this proposal was less than > favorable.

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

Hi Steve, On 02/02/18 18:04, Steven Rostedt wrote: > > At Kernel Summit back in October, we tried to bring up trace markers, which > would be nops within the kernel proper, that would allow modules to hook > arbitrary trace events to them. The reaction to this proposal was less than > favorable.

Re: [PATCH V2 3/7] sched/deadline: Keep new DL task within root domain's boundary

Hi Mathieu, On 01/02/18 09:51, Mathieu Poirier wrote: > When considering to move a task to the DL policy we need to make sure > the CPUs it is allowed to run on matches the CPUs of the root domains of > the runqueue it is currently assigned to. Otherwise the task will be > allowed to roam on

Re: [PATCH V2 3/7] sched/deadline: Keep new DL task within root domain's boundary

Hi Mathieu, On 01/02/18 09:51, Mathieu Poirier wrote: > When considering to move a task to the DL policy we need to make sure > the CPUs it is allowed to run on matches the CPUs of the root domains of > the runqueue it is currently assigned to. Otherwise the task will be > allowed to roam on

Re: [PATCH V2 2/7] cpuset: Rebuild root domain deadline accounting information

Hi Mathieu, On 01/02/18 09:51, Mathieu Poirier wrote: > When the topology of root domains is modified by CPUset or CPUhotplug > operations information about the current deadline bandwidth held in the > root domain is lost. > > This patch address the issue by recalculating the lost deadline >

Re: [PATCH V2 2/7] cpuset: Rebuild root domain deadline accounting information

Hi Mathieu, On 01/02/18 09:51, Mathieu Poirier wrote: > When the topology of root domains is modified by CPUset or CPUhotplug > operations information about the current deadline bandwidth held in the > root domain is lost. > > This patch address the issue by recalculating the lost deadline >

Re: [PATCH V2 1/7] sched/topology: Adding function partition_sched_domains_locked()

Hi Mathieu, On 01/02/18 09:51, Mathieu Poirier wrote: > 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. > > This

Re: [PATCH V2 1/7] sched/topology: Adding function partition_sched_domains_locked()

Hi Mathieu, On 01/02/18 09:51, Mathieu Poirier wrote: > 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. > > This

Re: [PATCH] Documentation/scheduler/sched-rt-group: Update SCHED DEADLINE references

off-by: Daniel Bristot de Oliveira <bris...@redhat.com> > Cc: Jonathan Corbet <cor...@lwn.net> > Cc: Juri Lelli <juri.le...@redhat.com> > Cc: Luca Abeni <luca.ab...@santannapisa.it> > Cc: Tommaso Cucinotta <tommaso.cucino...@santannapisa.it> > Cc

Re: [PATCH] Documentation/scheduler/sched-rt-group: Update SCHED DEADLINE references

off-by: Daniel Bristot de Oliveira > Cc: Jonathan Corbet > Cc: Juri Lelli > Cc: Luca Abeni > Cc: Tommaso Cucinotta > Cc: Claudio Scordino > Cc: Peter Zijlstra > Cc: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > > --- > Documentation/scheduler/sch

Re: [LTP] [lkp-robot] [sched/deadline] e0367b1267: WARNING:at_kernel/sched/sched.h:#assert_clock_updated

On 25/01/18 13:24, Cyril Hrubis wrote: > Hi! > > Hummm, wondering how LTP sched tests could trigger this, since a quick > > grep into ltp didn't show DEADLINE usage. > > See kernel/syscalls/sched_setattr/sched_setattr01.c Right, saw that. I was still thinking though why the report seemed to

Re: [LTP] [lkp-robot] [sched/deadline] e0367b1267: WARNING:at_kernel/sched/sched.h:#assert_clock_updated

On 25/01/18 13:24, Cyril Hrubis wrote: > Hi! > > Hummm, wondering how LTP sched tests could trigger this, since a quick > > grep into ltp didn't show DEADLINE usage. > > See kernel/syscalls/sched_setattr/sched_setattr01.c Right, saw that. I was still thinking though why the report seemed to

Re: [lkp-robot] [sched/deadline] e0367b1267: WARNING:at_kernel/sched/sched.h:#assert_clock_updated

Hi, On 25/01/18 14:28, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: e0367b12674bf4420870cd0237e3ebafb2ec9593 ("sched/deadline: Move CPU > frequency selection triggering points") >

Re: [lkp-robot] [sched/deadline] e0367b1267: WARNING:at_kernel/sched/sched.h:#assert_clock_updated

Hi, On 25/01/18 14:28, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: e0367b12674bf4420870cd0237e3ebafb2ec9593 ("sched/deadline: Move CPU > frequency selection triggering points") >

Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads

On 10/01/18 13:35, Rafael J. Wysocki wrote: > On Wed, Jan 10, 2018 at 11:54 AM, Juri Lelli <juri.le...@redhat.com> wrote: > > On 09/01/18 16:50, Rafael J. Wysocki wrote: > >> On Tue, Jan 9, 2018 at 3:43 PM, Leonard Crestez <leonard.cres...@nxp.com> > >>

Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads

On 10/01/18 13:35, Rafael J. Wysocki wrote: > On Wed, Jan 10, 2018 at 11:54 AM, Juri Lelli wrote: > > On 09/01/18 16:50, Rafael J. Wysocki wrote: > >> On Tue, Jan 9, 2018 at 3:43 PM, Leonard Crestez > >> wrote: > > > > [...] > > > &g

[tip:sched/core] sched/cpufreq: Move arch_scale_{freq,cpu}_capacity() outside of #ifdef CONFIG_SMP

Commit-ID: 7e1a9208f6c7e66bb4e5d2ed18dfd191230f431b Gitweb: https://git.kernel.org/tip/7e1a9208f6c7e66bb4e5d2ed18dfd191230f431b Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:24 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/cpufreq: Move arch_scale_{freq,cpu}_capacity() outside of #ifdef CONFIG_SMP

Commit-ID: 7e1a9208f6c7e66bb4e5d2ed18dfd191230f431b Gitweb: https://git.kernel.org/tip/7e1a9208f6c7e66bb4e5d2ed18dfd191230f431b Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:24 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 12:53:35 +0100 sched/cpufreq: Move

[tip:sched/core] sched/deadline: Make bandwidth enforcement scale-invariant

Commit-ID: 07881166a892fa4908ac4924660a7793f75d6544 Gitweb: https://git.kernel.org/tip/07881166a892fa4908ac4924660a7793f75d6544 Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:25 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/deadline: Make bandwidth enforcement scale-invariant

Commit-ID: 07881166a892fa4908ac4924660a7793f75d6544 Gitweb: https://git.kernel.org/tip/07881166a892fa4908ac4924660a7793f75d6544 Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:25 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 12:53:35 +0100 sched/deadline: Make

[tip:sched/core] sched/cpufreq: Change the worker kthread to SCHED_DEADLINE

Commit-ID: 794a56ebd9a57db12abaec63f038c6eb073461f7 Gitweb: https://git.kernel.org/tip/794a56ebd9a57db12abaec63f038c6eb073461f7 Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:20 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/cpufreq: Change the worker kthread to SCHED_DEADLINE

Commit-ID: 794a56ebd9a57db12abaec63f038c6eb073461f7 Gitweb: https://git.kernel.org/tip/794a56ebd9a57db12abaec63f038c6eb073461f7 Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:20 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 12:53:29 +0100 sched/cpufreq: Change

[tip:sched/core] sched/cpufreq: Always consider all CPUs when deciding next freq

Commit-ID: 0fa7d181f1a60149061632266bb432b4b61acdac Gitweb: https://git.kernel.org/tip/0fa7d181f1a60149061632266bb432b4b61acdac Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:22 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/cpufreq: Always consider all CPUs when deciding next freq

Commit-ID: 0fa7d181f1a60149061632266bb432b4b61acdac Gitweb: https://git.kernel.org/tip/0fa7d181f1a60149061632266bb432b4b61acdac Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:22 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 12:53:34 +0100 sched/cpufreq: Always

[tip:sched/core] sched/cpufreq: Remove arch_scale_freq_capacity()'s 'sd' parameter

Commit-ID: 7673c8a4c75d1cac2cd47156b9768f462683a09d Gitweb: https://git.kernel.org/tip/7673c8a4c75d1cac2cd47156b9768f462683a09d Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:23 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/cpufreq: Remove arch_scale_freq_capacity()'s 'sd' parameter

Commit-ID: 7673c8a4c75d1cac2cd47156b9768f462683a09d Gitweb: https://git.kernel.org/tip/7673c8a4c75d1cac2cd47156b9768f462683a09d Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:23 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 12:53:34 +0100 sched/cpufreq: Remove

[tip:sched/core] sched/cpufreq: Split utilization signals

Commit-ID: d18be45dbfef2e0bb12b9696c21aeae92f83b1ea Gitweb: https://git.kernel.org/tip/d18be45dbfef2e0bb12b9696c21aeae92f83b1ea Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:21 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/cpufreq: Split utilization signals

Commit-ID: d18be45dbfef2e0bb12b9696c21aeae92f83b1ea Gitweb: https://git.kernel.org/tip/d18be45dbfef2e0bb12b9696c21aeae92f83b1ea Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:21 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 12:53:34 +0100 sched/cpufreq: Split

[tip:sched/core] sched/deadline: Implement "runtime overrun signal" support

Commit-ID: 34be39305a77b8b1ec9f279163c7cdb6cc719b91 Gitweb: https://git.kernel.org/tip/34be39305a77b8b1ec9f279163c7cdb6cc719b91 Author: Juri Lelli <juri.le...@gmail.com> AuthorDate: Tue, 12 Dec 2017 12:10:24 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10

[tip:sched/core] sched/deadline: Implement "runtime overrun signal" support

Commit-ID: 34be39305a77b8b1ec9f279163c7cdb6cc719b91 Gitweb: https://git.kernel.org/tip/34be39305a77b8b1ec9f279163c7cdb6cc719b91 Author: Juri Lelli AuthorDate: Tue, 12 Dec 2017 12:10:24 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 11:30:31 +0100 sched/deadline: Implement

[tip:sched/core] sched/cpufreq: Use the DEADLINE utilization signal

Commit-ID: d4edd662ac1657126df7ffd74a278958b133a77d Gitweb: https://git.kernel.org/tip/d4edd662ac1657126df7ffd74a278958b133a77d Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:18 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/cpufreq: Use the DEADLINE utilization signal

Commit-ID: d4edd662ac1657126df7ffd74a278958b133a77d Gitweb: https://git.kernel.org/tip/d4edd662ac1657126df7ffd74a278958b133a77d Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:18 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 11:30:32 +0100 sched/cpufreq: Use

[tip:sched/core] sched/deadline: Move CPU frequency selection triggering points

Commit-ID: e0367b12674bf4420870cd0237e3ebafb2ec9593 Gitweb: https://git.kernel.org/tip/e0367b12674bf4420870cd0237e3ebafb2ec9593 Author: Juri Lelli <juri.le...@arm.com> AuthorDate: Mon, 4 Dec 2017 11:23:19 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 10 Ja

[tip:sched/core] sched/deadline: Move CPU frequency selection triggering points

Commit-ID: e0367b12674bf4420870cd0237e3ebafb2ec9593 Gitweb: https://git.kernel.org/tip/e0367b12674bf4420870cd0237e3ebafb2ec9593 Author: Juri Lelli AuthorDate: Mon, 4 Dec 2017 11:23:19 +0100 Committer: Ingo Molnar CommitDate: Wed, 10 Jan 2018 11:30:32 +0100 sched/deadline: Move CPU

Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads

On 09/01/18 16:50, Rafael J. Wysocki wrote: > On Tue, Jan 9, 2018 at 3:43 PM, Leonard Crestez > wrote: [...] > > Every 4 seconds (really it's /proc/sys/kernel/watchdog_thresh * 2 / 5 > > and watchdog_thresh defaults to 10). There is a per-cpu hrtimer which > > wakes

Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads

On 09/01/18 16:50, Rafael J. Wysocki wrote: > On Tue, Jan 9, 2018 at 3:43 PM, Leonard Crestez > wrote: [...] > > Every 4 seconds (really it's /proc/sys/kernel/watchdog_thresh * 2 / 5 > > and watchdog_thresh defaults to 10). There is a per-cpu hrtimer which > > wakes the per-cpu thread in order

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 22/12/17 12:50, Patrick Bellasi wrote: > On 22-Dec 13:43, Juri Lelli wrote: > > On 22/12/17 12:38, Patrick Bellasi wrote: > > > On 22-Dec 13:19, Peter Zijlstra wrote: > > > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote: > > > > >

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 22/12/17 12:50, Patrick Bellasi wrote: > On 22-Dec 13:43, Juri Lelli wrote: > > On 22/12/17 12:38, Patrick Bellasi wrote: > > > On 22-Dec 13:19, Peter Zijlstra wrote: > > > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote: > > > > >

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 22/12/17 12:38, Patrick Bellasi wrote: > On 22-Dec 13:19, Peter Zijlstra wrote: > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote: > > > > I was thinking that since dl is a 'global' scheduler the reservation > > > > would be too and thus the freq just needs a single CPU to be

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 22/12/17 12:38, Patrick Bellasi wrote: > On 22-Dec 13:19, Peter Zijlstra wrote: > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote: > > > > I was thinking that since dl is a 'global' scheduler the reservation > > > > would be too and thus the freq just needs a single CPU to be

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 22/12/17 13:19, Peter Zijlstra wrote: > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote: > > > I was thinking that since dl is a 'global' scheduler the reservation > > > would be too and thus the freq just needs a single CPU to be observed; > > > > AFAIU global is only the

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 22/12/17 13:19, Peter Zijlstra wrote: > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote: > > > I was thinking that since dl is a 'global' scheduler the reservation > > > would be too and thus the freq just needs a single CPU to be observed; > > > > AFAIU global is only the

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

Hi Peter, On 22/12/17 12:46, Peter Zijlstra wrote: > On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote: > > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct > > > sugov_cpu *sg_cpu, u64 time) > > > unsigned long j_util, j_max; > > > s64

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

Hi Peter, On 22/12/17 12:46, Peter Zijlstra wrote: > On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote: > > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct > > > sugov_cpu *sg_cpu, u64 time) > > > unsigned long j_util, j_max; > > > s64

[ANNOUNCE] OSPM-summit 2018 - Registrations are open!

Holla (Arm) Juri Lelli (Red Hat) Lorenzo Pieralisi (Arm) Morten Rasmussen (Arm) Claudio Scordino (Evidence SRL)

[ANNOUNCE] OSPM-summit 2018 - Registrations are open!

Holla (Arm) Juri Lelli (Red Hat) Lorenzo Pieralisi (Arm) Morten Rasmussen (Arm) Claudio Scordino (Evidence SRL)

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 20/12/17 16:30, Peter Zijlstra wrote: [...] > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar > if (delta_ns > TICK_NSEC) { > j_sg_cpu->iowait_boost = 0; > j_sg_cpu->iowait_boost_pending = false; > -

Re: [PATCH v3 0/6] cpufreq: schedutil: fixes for flags updates

On 20/12/17 16:30, Peter Zijlstra wrote: [...] > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar > if (delta_ns > TICK_NSEC) { > j_sg_cpu->iowait_boost = 0; > j_sg_cpu->iowait_boost_pending = false; > -

<    2   3   4   5   6   7   8   9   10   11   >