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
> task.
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
&
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
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 11:57
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
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,
on
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
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
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
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
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
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
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
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
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
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
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?
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
skip the rate limits when deadline asks for an
increase of frequency, as shown 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:0
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 abo
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:
git://git.kernel.
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
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
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
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
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
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
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 recal
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
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
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
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 SCHED_SETSCHEDULE
k has been 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: Claudi
: fix 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 --
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
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 to
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
37 matches
Mail list logo
