Re: [RFD/RFC PATCH 4/8] sched: Split scheduler execution context

Dear Juri, just a small comment for the next round of patches (I guess after OSPM)... On 091018, 11:24, Juri Lelli wrote: > From: Peter Zijlstra > > Lets define the scheduling context as all the scheduler state in > task_struct and the execution context as all state required to run the >

Re: [PATCH] kernel/time/posix-cpu-timers: Remove useless call to check_dl_overrun

ng (even though harmless). > > Remove it. > > Fixes: 34be39305a77 ("sched/deadline: Implement "runtime overrun signal" > support") > Signed-off-by: Juri Lelli > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Luca Abeni > Cc: Claudio Scordino &

Re: [PATCH] kernel/time/posix-cpu-timers: Remove useless call to check_dl_overrun

ng (even though harmless). > > Remove it. > > Fixes: 34be39305a77 ("sched/deadline: Implement "runtime overrun signal" > support") > Signed-off-by: Juri Lelli > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Luca Abeni > Cc: Claudio Scordino &

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

Hi Quentin, 2018-06-06 15:20 GMT+02:00 Quentin Perret : > > Hi Claudio, > > On Wednesday 06 Jun 2018 at 15:05:58 (+0200), Claudio Scordino wrote: > > Hi Quentin, > > > > Il 05/06/2018 16:13, Juri Lelli ha scritto: > > > On 05/06/18 15:01, Quentin Perret wrot

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

Hi Quentin, 2018-06-06 15:20 GMT+02:00 Quentin Perret : > > Hi Claudio, > > On Wednesday 06 Jun 2018 at 15:05:58 (+0200), Claudio Scordino wrote: > > Hi Quentin, > > > > Il 05/06/2018 16:13, Juri Lelli ha scritto: > > > On 05/06/18 15:01, Quentin Perret wrot

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

Hi Quentin, Il 05/06/2018 16:13, Juri Lelli ha scritto: On 05/06/18 15:01, Quentin Perret wrote: On Tuesday 05 Jun 2018 at 15:15:18 (+0200), Juri Lelli wrote: On 05/06/18 14:05, Quentin Perret wrote: On Tuesday 05 Jun 2018 at 14:11:53 (+0200), Juri Lelli wrote: Hi Quentin, On 05/06/18

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

Hi Quentin, Il 05/06/2018 16:13, Juri Lelli ha scritto: On 05/06/18 15:01, Quentin Perret wrote: On Tuesday 05 Jun 2018 at 15:15:18 (+0200), Juri Lelli wrote: On 05/06/18 14:05, Quentin Perret wrote: On Tuesday 05 Jun 2018 at 14:11:53 (+0200), Juri Lelli wrote: Hi Quentin, On 05/06/18

[tip:sched/core] sched/deadline/Documentation: Add overrun signal and GRUB-PA documentation

Commit-ID: bb4e30a48045c9cc16c4efe447489542750397cc Gitweb: https://git.kernel.org/tip/bb4e30a48045c9cc16c4efe447489542750397cc Author: Claudio Scordino <clau...@evidence.eu.com> AuthorDate: Tue, 3 Apr 2018 09:42:42 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/deadline/Documentation: Add overrun signal and GRUB-PA documentation

Commit-ID: bb4e30a48045c9cc16c4efe447489542750397cc Gitweb: https://git.kernel.org/tip/bb4e30a48045c9cc16c4efe447489542750397cc Author: Claudio Scordino AuthorDate: Tue, 3 Apr 2018 09:42:42 +0200 Committer: Ingo Molnar CommitDate: Mon, 14 May 2018 09:12:27 +0200 sched/deadline

Re: [RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests

Il 08/05/2018 08:54, Viresh Kumar ha scritto: On 07-05-18, 16:43, Claudio Scordino wrote: At OSPM, it was mentioned the issue about urgent CPU frequency requests arriving when a frequency switch is already in progress. Besides the various issues (physical time for switching frequency

Re: [RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests

Il 08/05/2018 08:54, Viresh Kumar ha scritto: On 07-05-18, 16:43, Claudio Scordino wrote: At OSPM, it was mentioned the issue about urgent CPU frequency requests arriving when a frequency switch is already in progress. Besides the various issues (physical time for switching frequency

[RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests

of energy consumption when running SCHED_DEADLINE tasks (not yet measured) is likely to be not negligible (especially in case of critical scenarios like "ramp up" utilizations). The patch is meant as follow-up discussion after OSPM. Signed-off-by: Claudio Scordino <clau...@evidence.e

[RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests

of energy consumption when running SCHED_DEADLINE tasks (not yet measured) is likely to be not negligible (especially in case of critical scenarios like "ramp up" utilizations). The patch is meant as follow-up discussion after OSPM. Signed-off-by: Claudio Scordino CC: Viresh Kumar CC: Rafael J

[PATCH] sched/deadline: add overrun signal and GRUB-PA in the documentation

Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> CC: Juri Lelli <juri.le...@redhat.com> CC: Luca Abeni <luca.ab...@santannapisa.it> CC: linux-kernel@vger.kernel.org CC: linux-...@vger.kernel.org --- Documentation/scheduler/sched-deadline.txt | 25 +++

[PATCH] sched/deadline: add overrun signal and GRUB-PA in the documentation

Signed-off-by: Claudio Scordino CC: Juri Lelli CC: Luca Abeni CC: linux-kernel@vger.kernel.org CC: linux-...@vger.kernel.org --- Documentation/scheduler/sched-deadline.txt | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/Documentation/scheduler

[tip:sched/core] sched/cpufreq: Rate limits for SCHED_DEADLINE

Commit-ID: e97a90f7069b740575bcb1dae86596e0484b8957 Gitweb: https://git.kernel.org/tip/e97a90f7069b740575bcb1dae86596e0484b8957 Author: Claudio Scordino <clau...@evidence.eu.com> AuthorDate: Tue, 13 Mar 2018 11:35:40 +0100 Committer: Thomas Gleixner <t...@linutronix.de> Com

[tip:sched/core] sched/cpufreq: Rate limits for SCHED_DEADLINE

Commit-ID: e97a90f7069b740575bcb1dae86596e0484b8957 Gitweb: https://git.kernel.org/tip/e97a90f7069b740575bcb1dae86596e0484b8957 Author: Claudio Scordino AuthorDate: Tue, 13 Mar 2018 11:35:40 +0100 Committer: Thomas Gleixner CommitDate: Fri, 23 Mar 2018 22:48:22 +0100 sched/cpufreq

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

of energy consumption (measured through Baylibre Cape). Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> Acked-by: Viresh Kumar <viresh.ku...@linaro.org> Reviewed-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> CC: Rafael J. Wysocki <rafael.j.wyso...@intel.

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

of energy consumption (measured through Baylibre Cape). Signed-off-by: Claudio Scordino Acked-by: Viresh Kumar Reviewed-by: Rafael J. Wysocki CC: Rafael J. Wysocki CC: Viresh Kumar CC: Patrick Bellasi CC: Dietmar Eggemann CC: Morten Rasmussen CC: Juri Lelli CC: Vincent Guittot CC: Todd

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

of energy consumption (measured through Baylibre Cape). Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> CC: Ingo Molnar <mi...@redhat.com> CC: Patrick Bellasi <patrick.bell...@arm.com> CC: Dietmar Eggemann <dietmar.eggem...@arm.com> CC: Morten Rasmussen <morten.

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

of energy consumption (measured through Baylibre Cape). Signed-off-by: Claudio Scordino CC: Ingo Molnar CC: Patrick Bellasi CC: Dietmar Eggemann CC: Morten Rasmussen CC: Juri Lelli CC: Viresh Kumar CC: Vincent Guittot CC: Todd Kjos CC: Joel Fernandes CC: linux...@vger.kernel.org CC: linux

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

Dear Rafael, dear Viresh, Il 28/02/2018 12:06, Claudio Scordino ha scritto: When the SCHED_DEADLINE scheduling class increases the CPU utilization, we should not wait for the rate limit, otherwise we may miss some deadline. Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks

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

Dear Rafael, dear Viresh, Il 28/02/2018 12:06, Claudio Scordino ha scritto: When the SCHED_DEADLINE scheduling class increases the CPU utilization, we should not wait for the rate limit, otherwise we may miss some deadline. Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks

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

of energy consumption (measured through Baylibre Cape). Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> CC: Ingo Molnar <mi...@redhat.com> CC: Patrick Bellasi <patrick.bell...@arm.com> CC: Dietmar Eggemann <dietmar.eggem...@arm.com> CC: Morten Rasmussen <morten.

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

of energy consumption (measured through Baylibre Cape). Signed-off-by: Claudio Scordino CC: Ingo Molnar CC: Patrick Bellasi CC: Dietmar Eggemann CC: Morten Rasmussen CC: Juri Lelli CC: Viresh Kumar CC: Vincent Guittot CC: Todd Kjos CC: Joel Fernandes CC: linux...@vger.kernel.org CC: linux

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

8 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 the CPU utilization, we should not wait for the rate limit, otherwise we may miss some deadline. Tests us

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

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

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

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 the CPU utilization, we should not wait for the rate limit, otherwise we may miss some deadline. Tests using rt-app on Exynos5422 have shown

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

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 the CPU utilization, we should not wait for the rate limit, otherwise we may miss some deadline. Tests using rt-app on Exynos5422 have shown

[PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

of the one recently proposed by Peter to drop the SCHED_CPUFREQ_* flags. Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> CC: Rafael J . Wysocki <rafael.j.wyso...@intel.com> CC: Patrick Bellasi <patrick.bell...@arm.com> CC: Dietmar Eggemann <dietmar.eggem...@arm.com&

[PATCH] cpufreq: schedutil: rate limits for SCHED_DEADLINE

of the one recently proposed by Peter to drop the SCHED_CPUFREQ_* flags. Signed-off-by: Claudio Scordino CC: Rafael J . Wysocki CC: Patrick Bellasi CC: Dietmar Eggemann CC: Morten Rasmussen CC: Juri Lelli CC: Viresh Kumar CC: Vincent Guittot CC: Todd Kjos CC: Joel Fernandes CC: linux

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

Hi Patrick, Il 06/02/2018 19:36, Patrick Bellasi ha scritto: On 06-Feb 19:14, Claudio Scordino wrote: Hi Patrick, At first glance, your proposal below makes to make sense. However, I'm wondering if we cannot get it working using rq->dl's provided information instead of flags? Yes, we

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

Hi Patrick, Il 06/02/2018 19:36, Patrick Bellasi ha scritto: On 06-Feb 19:14, Claudio Scordino wrote: Hi Patrick, At first glance, your proposal below makes to make sense. However, I'm wondering if we cannot get it working using rq->dl's provided information instead of flags? Yes, we

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

Hi Patrick, Il 06/02/2018 16:43, Patrick Bellasi ha scritto: Hi Claudio, On 06-Feb 11:55, Claudio Scordino wrote: Hi Peter, Il 20/12/2017 16:30, Peter Zijlstra ha scritto: So I ended up with the below (on top of Juri's cpufreq-dl patches). It compiles, but that's about all the testing

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

Hi Patrick, Il 06/02/2018 16:43, Patrick Bellasi ha scritto: Hi Claudio, On 06-Feb 11:55, Claudio Scordino wrote: Hi Peter, Il 20/12/2017 16:30, Peter Zijlstra ha scritto: So I ended up with the below (on top of Juri's cpufreq-dl patches). It compiles, but that's about all the testing

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

in the patch below. In this case, we could just remove the flags from sugov_cpu, but leave the defines and the argument for sugov_update_*() Best regards, Claudio From ed13fa5a8f93a43f8ff8f7d354b18c0031df482c Mon Sep 17 00:00:00 2001 From: Claudio Scordino <clau...@evidence.eu

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

in the patch below. In this case, we could just remove the flags from sugov_cpu, but leave the defines and the argument for sugov_update_*() Best regards, Claudio From ed13fa5a8f93a43f8ff8f7d354b18c0031df482c Mon Sep 17 00:00:00 2001 From: Claudio Scordino Date: Wed, 27 Sep 20

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

Hi Peter, Il 31/12/2017 10:43, Claudio Scordino ha scritto: Hi all, Il 20/12/2017 16:56, Peter Zijlstra ha scritto: On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote: So I ended up with the below (on top of Juri's cpufreq-dl patches). It compiles, but that's about all

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

Hi Peter, Il 31/12/2017 10:43, Claudio Scordino ha scritto: Hi all, Il 20/12/2017 16:56, Peter Zijlstra ha scritto: On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote: So I ended up with the below (on top of Juri's cpufreq-dl patches). It compiles, but that's about all

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

Hi all, Il 20/12/2017 16:56, Peter Zijlstra ha scritto: On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote: So I ended up with the below (on top of Juri's cpufreq-dl patches). It compiles, but that's about all the testing it had. Should all be available at:

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

Hi all, Il 20/12/2017 16:56, Peter Zijlstra ha scritto: On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote: So I ended up with the below (on top of Juri's cpufreq-dl patches). It compiles, but that's about all the testing it had. Should all be available at:

[PATCH v3] sched/deadline: runtime overrun signal

Signed-off-by: Juri Lelli <juri.le...@gmail.com> Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Luca Abeni <luca.ab...@santannapisa.it> Tested-by: Mathieu Poirier <mathieu.poir...@linaro.org> Cc: Tommaso Cucinotta <tommaso.cucino...@

[PATCH v3] sched/deadline: runtime overrun signal

Signed-off-by: Claudio Scordino Signed-off-by: Luca Abeni Tested-by: Mathieu Poirier Cc: Tommaso Cucinotta CC: Peter Zijlstra CC: Ingo Molnar CC: Thomas Gleixner CC: LKML CC: linux-rt-users --- Changes from v2: - do not use a dubious signed bitfield for the dl_overrun flag Changes from v1

[tip:sched/urgent] sched/deadline: Fix the description of runtime accounting in the documentation

Commit-ID: 5c0342ca7ef17220d8dd2da68d0d349c26ab19df Gitweb: https://git.kernel.org/tip/5c0342ca7ef17220d8dd2da68d0d349c26ab19df Author: Claudio Scordino <clau...@evidence.eu.com> AuthorDate: Tue, 14 Nov 2017 12:19:26 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/urgent] sched/deadline: Fix the description of runtime accounting in the documentation

Commit-ID: 5c0342ca7ef17220d8dd2da68d0d349c26ab19df Gitweb: https://git.kernel.org/tip/5c0342ca7ef17220d8dd2da68d0d349c26ab19df Author: Claudio Scordino AuthorDate: Tue, 14 Nov 2017 12:19:26 +0100 Committer: Ingo Molnar CommitDate: Thu, 16 Nov 2017 09:00:35 +0100 sched/deadline: Fix

[PATCH v2] sched/deadline: runtime overrun signal

Signed-off-by: Juri Lelli <juri.le...@gmail.com> Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Luca Abeni <luca.ab...@santannapisa.it> Tested-by: Mathieu Poirier <mathieu.poir...@linaro.org> Cc: Tommaso Cucinotta <tommaso.cucino...@

[PATCH v2] sched/deadline: runtime overrun signal

Signed-off-by: Claudio Scordino Signed-off-by: Luca Abeni Tested-by: Mathieu Poirier Cc: Tommaso Cucinotta CC: Peter Zijlstra CC: Ingo Molnar CC: Thomas Gleixner --- Changes from v1: - fix: do not send the signal in case of yield (reported by Mathieu) - removed the deadline miss signal

[PATCH v2] sched/deadline: fix runtime accounting in documentation

Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Luca Abeni <luca.ab...@santannapisa.it> Acked-by: Daniel Bristot de Oliveira <bris...@redhat.com> CC: Jonathan Corbet <cor...@lwn.net> CC: "Peter Zijlstra (Intel)" <pet...@infradead.org&g

[PATCH v2] sched/deadline: fix runtime accounting in documentation

Signed-off-by: Claudio Scordino Signed-off-by: Luca Abeni Acked-by: Daniel Bristot de Oliveira CC: Jonathan Corbet CC: "Peter Zijlstra (Intel)" CC: Ingo Molnar CC: linux-...@vger.kernel.org Cc: Tommaso Cucinotta Cc: Mathieu Poirier --- Documentation/scheduler/sched-deadlin

[PATCH] sched/deadline: runtime overrun and deadline miss signals

ml.org/lkml/2009/10/16/170 Signed-off-by: Juri Lelli <juri.le...@gmail.com> Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Luca Abeni <luca.ab...@santannapisa.it> Cc: Tommaso Cucinotta <tommaso.cucino...@sssup.it> CC: Peter Zijlstra <pet...@i

[PATCH] sched/deadline: runtime overrun and deadline miss signals

Signed-off-by: Juri Lelli Signed-off-by: Claudio Scordino Signed-off-by: Luca Abeni Cc: Tommaso Cucinotta CC: Peter Zijlstra CC: Ingo Molnar CC: Thomas Gleixner Cc: Mathieu Poirier --- include/linux/sched.h | 8 include/uapi/linux/sched.h | 2 ++ kernel/sched/core.c

[PATCH] sched/deadline: fix runtime accounting in documentation

Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Luca Abeni <luca.ab...@santannapisa.it> --- Documentation/scheduler/sched-deadline.txt | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/scheduler/sched-dea

[PATCH] sched/deadline: fix runtime accounting in documentation

Signed-off-by: Claudio Scordino Signed-off-by: Luca Abeni --- Documentation/scheduler/sched-deadline.txt | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt index e89e36e

Re: [PATCH] sched/deadline: add GRUB bw change tracepoints

Ouch, you'right. Now that I recall, you provided the first draft for internal debugging but it was Luca who agreed to add it to the patchset. Sorry for the mistake guys. Best, Claudio 2017-07-04 15:12 GMT+02:00 Claudio Scordino <clau...@evidence.eu.com>: > Ouch, you'right. >

Re: [PATCH] sched/deadline: add GRUB bw change tracepoints

Ouch, you'right. Now that I recall, you provided the first draft for internal debugging but it was Luca who agreed to add it to the patchset. Sorry for the mistake guys. Best, Claudio 2017-07-04 15:12 GMT+02:00 Claudio Scordino : > Ouch, you'right. > > Now that I recall, you

[PATCH] sched/deadline: add GRUB bw change tracepoints

This patch adds a tracepoint for tracing the total and running bandwidths of GRUB's runqueue. Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Juri Lelli <juri.le...@arm.com> Signed-off-by: Luca Abeni <luca.ab...@santannapisa.it> --- include/trace/e

[PATCH] sched/deadline: add GRUB bw change tracepoints

This patch adds a tracepoint for tracing the total and running bandwidths of GRUB's runqueue. Signed-off-by: Claudio Scordino Signed-off-by: Juri Lelli Signed-off-by: Luca Abeni --- include/trace/events/sched.h | 32 kernel/sched/deadline.c | 11

[tip:sched/core] sched/deadline: Add documentation about GRUB reclaiming

Commit-ID: ccc9d651a7d26fec88d2375c4dd4e097cc0f8de7 Gitweb: http://git.kernel.org/tip/ccc9d651a7d26fec88d2375c4dd4e097cc0f8de7 Author: Claudio Scordino <clau...@evidence.eu.com> AuthorDate: Thu, 18 May 2017 22:13:37 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate

[tip:sched/core] sched/deadline: Add documentation about GRUB reclaiming

Commit-ID: ccc9d651a7d26fec88d2375c4dd4e097cc0f8de7 Gitweb: http://git.kernel.org/tip/ccc9d651a7d26fec88d2375c4dd4e097cc0f8de7 Author: Claudio Scordino AuthorDate: Thu, 18 May 2017 22:13:37 +0200 Committer: Ingo Molnar CommitDate: Thu, 8 Jun 2017 10:31:56 +0200 sched/deadline: Add

Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization

Hi guys, 2017-03-27 10:20 GMT+02:00 Luca Abeni : > On Fri, 24 Mar 2017 22:31:46 -0400 > Steven Rostedt wrote: > >> On Fri, 24 Mar 2017 22:47:15 +0100 >> luca abeni wrote: >> >> > Ok... Since I am not good at ascii art,

Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization

Hi guys, 2017-03-27 10:20 GMT+02:00 Luca Abeni : > On Fri, 24 Mar 2017 22:31:46 -0400 > Steven Rostedt wrote: > >> On Fri, 24 Mar 2017 22:47:15 +0100 >> luca abeni wrote: >> >> > Ok... Since I am not good at ascii art, would it be ok to add a >> > textual description? If yes, I'll add a comment

Re: sched_{set,get}attr() manpage

Il 10/04/2014 09:47, Juri Lelli ha scritto: Hi all, On Wed, 9 Apr 2014 17:42:04 +0200 Peter Zijlstra wrote: On Wed, Apr 09, 2014 at 05:19:11PM +0200, Henrik Austad wrote: The following "real-time" policies are also supported, for why the "'s? I borrowed those from

Re: sched_{set,get}attr() manpage

Il 10/04/2014 09:47, Juri Lelli ha scritto: Hi all, On Wed, 9 Apr 2014 17:42:04 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, Apr 09, 2014 at 05:19:11PM +0200, Henrik Austad wrote: The following real-time policies are also supported, for why the 's? I borrowed those from

[PATCH RESEND] umc-bus.c: fix usage of device_trylock

acquired successfully. Best regards, Claudio Subject: umc-bus.c: fix usage of device_trylock From: Claudio Scordino Fix usage of device_trylock. It has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Signed-off-by: Claudio Scordino

[PATCH RESEND] umc-bus.c: fix usage of device_trylock

acquired successfully. Best regards, Claudio Subject: umc-bus.c: fix usage of device_trylock From: Claudio Scordino clau...@evidence.eu.com Fix usage of device_trylock. It has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Signed-off

[PATCH] umc-bus.c: fix usage of device_trylock

usage of device_trylock From: Claudio Scordino device_trylock has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Signed-off-by: Claudio Scordino --- drivers/uwb/umc-bus.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

[PATCH] umc-bus.c: fix usage of device_trylock

usage of device_trylock From: Claudio Scordino clau...@evidence.eu.com device_trylock has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Signed-off-by: Claudio Scordino clau...@evidence.eu.com --- drivers/uwb/umc-bus.c |2 +- 1 files changed, 1

Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun

Il 20/07/2012 17:15, Greg KH ha scritto: On Fri, Jul 20, 2012 at 12:26:10PM +0200, Claudio Scordino wrote: Il 20/07/2012 00:58, Greg KH ha scritto: On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote: Il 06/07/2012 19:41, Greg KH ha scritto: On Wed, Jun 27, 2012 at 06:01:39PM

Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun

Il 20/07/2012 17:15, Greg KH ha scritto: On Fri, Jul 20, 2012 at 12:26:10PM +0200, Claudio Scordino wrote: Il 20/07/2012 00:58, Greg KH ha scritto: On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote: Il 06/07/2012 19:41, Greg KH ha scritto: On Wed, Jun 27, 2012 at 06:01:39PM

Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun

Il 20/07/2012 00:58, Greg KH ha scritto: On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote: Il 06/07/2012 19:41, Greg KH ha scritto: On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote: Hi Olav, please find below a patch for the isp1362-hcd.c driver

Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun

Il 20/07/2012 00:58, Greg KH ha scritto: On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote: Il 06/07/2012 19:41, Greg KH ha scritto: On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote: Hi Olav, please find below a patch for the isp1362-hcd.c driver

Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun

Il 06/07/2012 19:41, Greg KH ha scritto: On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote: Hi Olav, please find below a patch for the isp1362-hcd.c driver to always save the message in case of underrun. More information is provided inside the patch comment. Let us know

Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun

Il 06/07/2012 19:41, Greg KH ha scritto: On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote: Hi Olav, please find below a patch for the isp1362-hcd.c driver to always save the message in case of underrun. More information is provided inside the patch comment. Let us know