Hi,
still digesting this change, but I'll point out below why I think you
are hitting a NULL ptr dereference (discussed on IRC).
On 07/06/16 21:56, Peter Zijlstra wrote:
> With the introduction of SCHED_DEADLINE the whole notion that priority
> is a single number is gone, therefore the @prio argu
On 14/06/16 20:53, Xunlei Pang wrote:
> On 2016/06/14 at 18:21, Juri Lelli wrote:
> > Hi,
> >
> > On 07/06/16 21:56, Peter Zijlstra wrote:
> >> From: Xunlei Pang
> >>
> >> A crash happened while I was playing with deadline PI rtmutex.
> &g
On 14/06/16 14:32, Peter Zijlstra wrote:
> On Tue, Jun 14, 2016 at 01:08:13PM +0100, Juri Lelli wrote:
> > > + postunlock = rt_mutex_futex_unlock(&pi_state->pi_mutex, &wake_q);
> > >
> > > /*
> > >* First unlock HB so the waiter does no
Hi,
On 07/06/16 21:56, Peter Zijlstra wrote:
> Previous patches changed the meaning of the return value of
> rt_mutex_slowunlock(); update comments and code to reflect this.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> kernel/futex.c | 12 ++--
> kernel/locking/r
dl_prio() condition.
>
> [peterz: I should introduce more task state comparators like
> rt_mutex_waiter_less, all PI prio comparisons already have this DL
> exception, except this one]
>
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: Juri Lelli
> Signed-of
ock, and remove rt_mutex_adjust_prio(). Since
> now we moved the deboost point, in order to avoid current to be
> preempted due to deboost earlier before wake_up_q(), we also moved
> preempt_disable() before unlocking rtmutex.
>
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Cc: Juri Lell
ext patch, where we have rt_mutex_setprio() cache a pointer to
> the top-most waiter task. If we, as before this change, do the wakeup
> first and then deboost, this pointer might point into thin air.
>
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Cc: Juri Lelli
> Suggested-
On 07/06/16 12:26, Daniel Bristot de Oliveira wrote:
> Ciao Juri,
>
> On 06/07/2016 10:30 AM, Juri Lelli wrote:
> > So, this and the partitioned one could actually overlap, since we don't
> > set cpu_exclusive. Is that right?
> >
> > I guess affinity mask
On 07/06/16 09:39, Daniel Bristot de Oliveira wrote:
> Ciao Juri,
>
Ciao, :-)
> On 06/07/2016 07:14 AM, Juri Lelli wrote:
> > Interesting. And your test is using cpuset controller to partion
> > DEADLINE tasks and then modify groups concurrently?
>
> Yes. I wa
Hi,
On 06/06/16 19:24, Daniel Bristot de Oliveira wrote:
> While testing the deadline scheduler + cgroup setup I hit this
> warning.
>
> [ 132.612935] [ cut here ]
> [ 132.612951] WARNING: CPU: 5 PID: 0 at kernel/softirq.c:150
> __local_bh_enable_ip+0x6b/0x80
> [ 132.6
On 02/06/16 18:27, Dietmar Eggemann wrote:
> On 02/06/16 10:25, Juri Lelli wrote:
>
> [...]
>
> >> @@ -2757,7 +2754,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg
> >> *sa,
> >>
On 02/06/16 16:53, Dietmar Eggemann wrote:
> On 02/06/16 10:23, Juri Lelli wrote:
>
> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >> index 218f8e83db73..212becd3708f 100644
> >> --- a/kernel/sched/fair.c
> >> +++ b/kernel/sched/fair.c
&g
Hi,
another minor comment below. :-)
On 01/06/16 20:39, Dietmar Eggemann wrote:
> The information whether a se/cfs_rq should get its load and
> utilization (se representing a task and root cfs_rq) or only its load
> (se representing a task group and cfs_rq owned by this se) updated can
> be passe
Hi,
minor comment below.
On 01/06/16 20:39, Dietmar Eggemann wrote:
> cpu utilization (cpu_util()) is defined as the cpu (original) capacity
> capped cfs_rq->avg->util_avg signal of the root cfs_rq.
>
> With the current pelt version, the utilization of a task [en|de]queued
> on/from a cfs_rq, re
Hi Tommaso,
On 18/05/16 00:43, Tommaso Cucinotta wrote:
> On 17/05/2016 13:46, luca abeni wrote:
> >Maybe the ... change can be split in a separate
> >patch, which is a bugfix (and IMHO uncontroversial)?
>
> Ok, the bugfix alone might look like the attached. Couldn't avoid
> the little refactorin
r managed to
send it out, sorry about that. We can take yours, mine follows just in
case we want to take something from the changelog or we want to reverse
the if condition.
Thanks,
- Juri
--->8---
>From 4bf38111bd9383035e03d3dc3d42011aaa9e26e7 Mon Sep 17 00:00:00 2001
From: Juri Lelli
Date:
On 13/04/16 02:37, Bill Huey (hui) wrote:
> [Trying to resend this so that linux-kernel mailer doesn't reject it.
> ok just found plain text mode. Will cull the CC list in future
> responses]
>
> Hi Juri,
>
> It's not for replacing deadline first of all. I'm not fully aware of the
> kind of thing
On 13/04/16 02:07, Yuyang Du wrote:
> On Tue, Apr 12, 2016 at 11:14:13AM +0100, Juri Lelli wrote:
> > On 12/04/16 03:12, Yuyang Du wrote:
> > > On Mon, Apr 11, 2016 at 11:41:28AM +0100, Juri Lelli wrote:
> > > > Hi,
> > > >
[+Luca, as he might be interested]
Hi,
On 11/04/16 22:29, Bill Huey (hui) wrote:
> Hi,
>
> This a crude cyclic scheduler implementation. It uses SCHED_FIFO tasks
> and runs them according to a map pattern specified by a 64 bit mask. Each
> bit corresponds to an entry into an 64 entry array of
>
On 11/04/16 16:21, Joe Perches wrote:
> On Mon, 2016-04-11 at 17:59 +0100, Dietmar Eggemann wrote:
> []
> > IMHO, it would be nice to add this to the existing tool from the patch
> > header of commit 5b51f2f80b3b
> > ("sched: Make __update_entity_runnable_avg() fast") simply because people
> > alre
On 12/04/16 03:12, Yuyang Du wrote:
> On Mon, Apr 11, 2016 at 11:41:28AM +0100, Juri Lelli wrote:
> > Hi,
> >
> > On 11/04/16 06:36, Yuyang Du wrote:
> > > __compute_runnable_contrib() uses a loop to compute sum, whereas a
> > > table loopup can do it fast
Hi,
On 11/04/16 06:36, Yuyang Du wrote:
> __compute_runnable_contrib() uses a loop to compute sum, whereas a
> table loopup can do it faster in a constant time.
>
> The following python script can be used to generate the constants:
>
> print " #: yN_inv yN_sum"
> print "---
Hi,
On 08/04/16 12:54, Peter Zijlstra wrote:
> On Fri, Apr 08, 2016 at 03:31:41AM -0700, Joe Perches wrote:
> > On Fri, 2016-04-08 at 10:07 +0800, Yuyang Du wrote:
> > > __compute_runnable_contrib() uses a loop to compute sum, whereas a
> > > table lookup can do it faster in a constant time.
> >
Hi,
On 29/03/16 15:25, Steven Rostedt wrote:
> On Tue, 29 Mar 2016 16:12:38 -0300
> Daniel Bristot de Oliveira wrote:
>
> > On 03/29/2016 02:13 PM, Steven Rostedt wrote:
> > >> -0 [007] d..3 78377.688969: sched_switch:
> > >> prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state
On 21/03/16 17:51, Mark Brown wrote:
> On Mon, Mar 21, 2016 at 05:24:52PM +0000, Juri Lelli wrote:
>
> > I think this should work, but we have to understand how do we obtain the
> > max frequency of each cluster while parsing DT. OPP bindings are
> > helpful, but AFAIK
Hi Mark,
On 21/03/16 12:12, Mark Brown wrote:
> On Mon, Mar 21, 2016 at 11:49:56AM +0000, Juri Lelli wrote:
>
> > But we'll still need to normalize this w.r.t the highest score we get on
> > a specific platform, right? And while we are at normalizing it, it is
> > pr
Hi Vincent,
On 21/03/16 12:09, Vincent Guittot wrote:
> On 21 March 2016 at 11:53, Juri Lelli wrote:
> > Hi Sai,
> >
> > On 18/03/16 10:49, Sai Gurrappadi wrote:
> >> Hi Juri,
> >>
> &
On 19/03/16 20:15, Rob Herring wrote:
> On Fri, Mar 18, 2016 at 02:24:08PM +0000, Juri Lelli wrote:
> > ARM systems may be configured to have cpus with different power/performance
> > characteristics within the same chip. In this case, additional information
> > has to be
Hi Sai,
On 18/03/16 10:49, Sai Gurrappadi wrote:
> Hi Juri,
>
> On 03/18/2016 07:24 AM, Juri Lelli wrote:
>
>
>
> > +
> > +==
> > +2 - CPU capacity definition
> > +=
Add TC2 cpu capacity binding information.
Cc: Liviu Dudau
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: devicet...@vger.kernel.org
Signed-off-by: Juri Lelli
---
Changes from v1:
- capacity
Hi Rafael,
On 17/03/16 01:01, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
[...]
> +static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
> + unsigned int next_freq)
> +{
> + struct cpufreq_policy *policy = sg_policy->policy;
> +
> +
Instead of looping through all cpus calling set_capacity_scale, we can
initialise cpu_scale per-cpu variables to SCHED_CAPACITY_SCALE with their
definition.
Cc: Russell King
Acked-by: Vincent Guittot
Signed-off-by: Juri Lelli
---
Applied:
http://www.arm.linux.org.uk/developer/patches
information provided by this patch will start to be used in
the future, by properly defining arch_scale_cpu_capacity().
Cc: Russell King
Signed-off-by: Juri Lelli
---
Changes from v1:
- normalize w.r.t. highest capacity found in DT
- bailout conditions (all-or-nothing)
---
arch/arm/kernel
Marinas
Cc: Will Deacon
Cc: Mark Brown
Cc: Sudeep Holla
Signed-off-by: Juri Lelli
---
arch/arm64/kernel/topology.c | 68
1 file changed, 68 insertions(+)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 69229b3..4d1fddb
outside the scope of this posting.
Best,
- Juri
[1] v1 - https://lkml.org/lkml/2015/11/23/391
v2 - https://lkml.org/lkml/2016/1/8/417
v3 - https://lkml.org/lkml/2016/2/3/405
[2] https://lkml.org/lkml/2015/7/7/754
Juri Lelli (8):
ARM: initialize cpu_scale to its default
Documentation: ar
Hi,
On 17/03/16 15:53, Patrick Bellasi wrote:
> On 17-Mar 06:55, Steve Muckle wrote:
> > On 03/17/2016 02:40 AM, Juri Lelli wrote:
> > >> Could the default schedtune value not serve as the out of the box margin?
> > >>
> > > I'm not sure I understan
On 16/03/16 10:55, Steve Muckle wrote:
> On 03/16/2016 03:02 AM, Juri Lelli wrote:
> > Hi,
> >
> > On 16/03/16 09:05, Peter Zijlstra wrote:
> >> On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
> >>>> Then again, maybe this knob
Signed-off-by: Juri Lelli
---
arch/arm/kernel/topology.c | 68 ++
1 file changed, 68 insertions(+)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 53c13c1..28a4029 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel
...@vger.kernel.org
Signed-off-by: Juri Lelli
---
Changes from v1:
- capacity-scale removed
---
arch/arm64/boot/dts/arm/juno.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index dcfcf15..a15c781 100644
--- a/arch/arm64
On 17/03/16 12:40, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 11:35:07AM +0000, Juri Lelli wrote:
>
> > > + pr_warn("cpufreq: CPU%u: Fast freqnency switching not
> > > enabled\n",
> >
> > Ultra-minor nit: s/freqnency/frequency/
>
deal with heterogeneity.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Maxime Ripard
Cc: Olof Johansson
Cc: Gregory CLEMENT
Cc: Paul Walmsley
Cc: Linus Walleij
Cc: Chen-Yu Tsai
Cc: Thomas Petazzoni
Cc: devicet...@vger.kernel.org
Signed-off-by: Juri
Hi,
On 17/03/16 00:51, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: [PATCH] cpufreq: Support for fast frequency switching
>
[...]
> +void cpufreq_enable_fast_switch(struct cpufreq_policy *policy)
> +{
> + lockdep_assert_held(&policy->rwsem);
> +
> + mutex_lock(&cpufreq
properly defining arch_scale_cpu_capacity().
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Brown
Cc: Sudeep Holla
Signed-off-by: Juri Lelli
---
Changes from v1:
- normalize w.r.t. highest capacity found in DT
- bailout conditions (all-or-nothing)
---
arch/arm64/kernel/topology.c | 75
Hi,
On 16/03/16 09:05, Peter Zijlstra wrote:
> On Tue, Mar 15, 2016 at 08:36:57PM -0700, Steve Muckle wrote:
> > > Then again, maybe this knob will be part of the mythical
> > > power-vs-performance slider?
> >
> > Patrick Bellasi's schedtune series [0] (which I think is the referenced
> > mythic
On 10/03/16 00:41, Rafael J. Wysocki wrote:
> On Wed, Mar 9, 2016 at 11:15 AM, Juri Lelli wrote:
> > Hi,
> >
> > sorry if I didn't reply yet. Trying to cope with jetlag and
> > talks/meetings these days :-). Let me see if I'm getting what you are
> > di
Hi,
sorry if I didn't reply yet. Trying to cope with jetlag and
talks/meetings these days :-). Let me see if I'm getting what you are
discussing, though.
On 08/03/16 21:05, Rafael J. Wysocki wrote:
> On Tue, Mar 8, 2016 at 8:26 PM, Peter Zijlstra wrote:
> > On Tue, Mar 08, 2016 at 07:00:57PM +01
Hi Rafael,
On 04/03/16 04:35, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add a new cpufreq scaling governor, called "schedutil", that uses
> scheduler-provided CPU utilization information as input for making
> its decisions.
>
> Doing that is possible after commit fe7034338ba0 (cpuf
Hi Rafael,
On 04/03/16 04:18, Rafael J. Wysocki wrote:
[...]
> +/**
> + * cpufreq_update_util - Take a note about CPU utilization changes.
> + * @time: Current time.
> + * @util: CPU utilization.
> + * @max: CPU capacity.
> + *
> + * This function is called on every invocation of update_load_avg
On 03/03/16 17:56, Peter Zijlstra wrote:
> On Thu, Mar 03, 2016 at 04:55:44PM +0000, Juri Lelli wrote:
> > On 03/03/16 17:37, Peter Zijlstra wrote:
> > > But given the platform's cpuidle information, maybe coupled with an avg
> > > idle est, we can compute the
On 03/03/16 17:37, Peter Zijlstra wrote:
> On Thu, Mar 03, 2016 at 05:24:32PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Mar 3, 2016 at 1:20 PM, Peter Zijlstra wrote:
> > > On Wed, Mar 02, 2016 at 11:49:48PM +0100, Rafael J. Wysocki wrote:
> > >> >>> + min_f = sg_policy->policy->cpuinfo.min
Hi Steve,
On 03/03/16 09:23, Steven Rostedt wrote:
> On Thu, 3 Mar 2016 09:28:01 +
> Juri Lelli wrote:
>
> > That's the one that I use, and I'm not seeing any problems with it. I'll
> > send you the binary in private.
>
> That's the one
On 03/03/16 13:20, Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 11:49:48PM +0100, Rafael J. Wysocki wrote:
> > >>> + min_f = sg_policy->policy->cpuinfo.min_freq;
> > >>> + max_f = sg_policy->policy->cpuinfo.max_freq;
> > >>> + next_f = util > max ? max_f : min_f + util * (max_f
Hi,
On 02/03/16 03:04, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
[...]
> @@ -95,18 +98,24 @@ EXPORT_SYMBOL_GPL(cpufreq_set_update_uti
> *
> * This function is called by the scheduler on every invocation of
> * update_load_avg() on the CPU whose utilization is being updated.
>
On 02/03/16 19:50, Steve Muckle wrote:
> On 03/02/2016 06:49 PM, Rafael J. Wysocki wrote:
> > I'm not actually sure if RT is the right answer here. DL may be a
> > better choice. After all, we want the thing to happen shortly, but
> > not necessarily at full speed.
> >
> > So something like a DL
Hi Luca,
On 03/03/16 10:03, Luca Abeni wrote:
> On Thu, 25 Feb 2016 09:46:55 +
> Juri Lelli wrote:
>
> > Hi,
> >
> > On 24/02/16 14:53, luca abeni wrote:
> > > On Tue, 23 Feb 2016 16:42:49 +0100
> > > Peter Zijlstra wrote:
> > >
On 26/02/16 03:36, Rafael J. Wysocki wrote:
> On Thursday, February 25, 2016 11:01:20 AM Juri Lelli wrote:
[...]
> >
> > That is right. But, can't an higher priority class eat all the needed
> > capacity. I mean, suppose that both CFS and DL need 30% of CPU capacity
&g
On 01/03/16 15:26, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 03:24:59PM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 01, 2016 at 02:17:06PM +0000, Juri Lelli wrote:
> > > On 01/03/16 14:58, Peter Zijlstra wrote:
> > > > On Fri, Feb 12, 2016 at 03:48:54P
On 01/03/16 14:58, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
>
> > Another point to take into account is that the RT tasks will "steal"
> > the compute capacity that has been requested by the cfs tasks.
> >
> > Let takes the example of a CPU with 3 O
to me that switched_to_dl() is never invoked, for some
> > reason...)
>
> Hmm, it should be invoked if you do sched_setattr() to get
> SCHED_DEADLINE.
>
> ---
> Subject: sched/deadline: Remove superfluous call to switched_to_dl()
>
> if (A || B) {
>
>
On 23/02/16 00:02, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2016 at 3:16 PM, Juri Lelli wrote:
> > Hi Rafael,
>
> Hi,
>
Sorry, my reply to this got delayed a bit.
> > thanks for this RFC. I'm going to test it more in the next few days, but
> > I alread
Hi Peter,
On 24/02/16 20:17, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 06:05:30PM +0100, Peter Zijlstra wrote:
> > Having two separate means of accounting this also feels more fragile
> > than one would want.
> >
> > Let me think a bit about this.
>
> I think there's a fundamental problem
Hi,
On 24/02/16 14:53, luca abeni wrote:
> On Tue, 23 Feb 2016 16:42:49 +0100
> Peter Zijlstra wrote:
>
> > On Mon, Feb 22, 2016 at 11:57:04AM +0100, Luca Abeni wrote:
> > > switched_to_dl() can be used instead
> >
> > This seems unrelated to the other patches, and looks like a nice
> > cleanup
On 23/02/16 16:48, Peter Zijlstra wrote:
> On Wed, Feb 10, 2016 at 01:42:40PM +0000, Juri Lelli wrote:
> > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > > index 9503d59..0ee0ec2 100644
> > > > --- a/kernel/sched/core.c
> > > > +
On 22/02/16 22:41, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2016 at 10:42 AM, Juri Lelli wrote:
> > Hi Rafael,
> >
> > On 19/02/16 23:26, Rafael J. Wysocki wrote:
> >> On Friday, February 19, 2016 05:26:04 PM Juri Lelli wrote:
> >> > Hi Srinivas,
On 22/02/16 22:26, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2016 at 10:32 AM, Juri Lelli wrote:
> > On 19/02/16 23:14, Rafael J. Wysocki wrote:
> >> On Friday, February 19, 2016 08:09:17 AM Juri Lelli wrote:
> >> > Hi Rafael,
> >> >
> >> > O
Hi,
On 22/02/16 17:30, Steven Rostedt wrote:
> On Mon, 22 Feb 2016 22:30:17 +0100
> Peter Zijlstra wrote:
>
> > On Mon, Feb 22, 2016 at 12:48:54PM -0500, Steven Rostedt wrote:
> >
[...]
> >
> > > But let me ask, what would you recommend to finding out if the kernel
> > > has really given you
oblem may exist.
>
[...]
>
> Signed-off-by: Steven Rostedt
This is pretty useful yes.
FWIW,
Acked-by: Juri Lelli
Best,
- Juri
Hi Peter,
On 22/02/16 11:52, Peter Zijlstra wrote:
> On Fri, Feb 19, 2016 at 09:28:23AM -0800, Steve Muckle wrote:
> > On 02/19/2016 08:42 AM, Srinivas Pandruvada wrote:
> > > We did experiments using util/max in intel_pstate. For some benchmarks
> > > there were regression of 4 to 5%, for some be
Hi Rafael,
thanks for this RFC. I'm going to test it more in the next few days, but
I already have some questions from skimming through it. Please find them
inline below.
On 22/02/16 00:18, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add a new cpufreq scaling governor, called "schedu
On 22/02/16 19:32, Pingbo Wen wrote:
> Hi, Juri
>
> On Monday, February 22, 2016 06:53 PM, Juri Lelli wrote:
> > Hi,
> >
> > On 20/02/16 19:32, Pingbo Wen wrote:
> >> Fix null pointer dereference error liked below. This BUG can be easily
> >> re-prod
Hi,
On 20/02/16 19:32, Pingbo Wen wrote:
> Fix null pointer dereference error liked below. This BUG can be easily
> re-produced by 'monkey --throttle 50' in android 6.0.
>
I'm not sure which code base you are looking at here, but I think this
problem has already been noticed and fixed by Ricky.
Hi Rafael,
On 19/02/16 23:26, Rafael J. Wysocki wrote:
> On Friday, February 19, 2016 05:26:04 PM Juri Lelli wrote:
> > Hi Srinivas,
> >
> > On 19/02/16 08:42, Srinivas Pandruvada wrote:
> > > On Fri, 2016-02-19 at 08:09 +, Juri Lelli wrote:
> > >
On 19/02/16 23:14, Rafael J. Wysocki wrote:
> On Friday, February 19, 2016 08:09:17 AM Juri Lelli wrote:
> > Hi Rafael,
> >
> > On 18/02/16 21:22, Rafael J. Wysocki wrote:
> > > On Mon, Feb 15, 2016 at 10:47 PM, Rafael J. Wysocki
> > >
Hi Srinivas,
On 19/02/16 08:42, Srinivas Pandruvada wrote:
> On Fri, 2016-02-19 at 08:09 +0000, Juri Lelli wrote:
> Hi Juri,
> > >
> > Hi Rafael,
> >
> > On 18/02/16 21:22, Rafael J. Wysocki wrote:
> > > On Mon, Feb 15, 2016 at 10:47 PM, Rafael J. Wysoc
Hi Steve,
On 18/02/16 09:15, Steven Rostedt wrote:
> On Tue, 16 Feb 2016 18:37:46 -0500
> Steven Rostedt wrote:
>
> >
> > A better solution may be to subtract the bandwidth that the deadline
> > task uses from the rt_runtime, and add it back when its finished. Then
> > there wont be a need for
Hi Rafael,
On 18/02/16 21:22, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 10:47 PM, Rafael J. Wysocki
> wrote:
> > From: Rafael J. Wysocki
> >
[...]
>
> So if anyone has any issues with this one, please let me know.
>
I'm repeating myself a bit, but I'll try to articulate my only co
Hi,
On 12/02/16 18:10, Steven Rostedt wrote:
> I'm writing a test case for SCHED_DEADLINE, and notice a strange
> anomaly. Every so often, a deadline is missed and when I looked into
> it, it happened because the sched_yield() had no effect (it didn't end
> the previous period and let the start of
On 12/02/16 18:05, Peter Zijlstra wrote:
> On Thu, Feb 11, 2016 at 05:10:12PM +0000, Juri Lelli wrote:
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 6368f43..1eccecf 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/dea
y tested it with Steve's test and I don't see the warning
anymore (sched_debug looks good as well); but my confidence is still
pretty low. :(
--->8---
>From 9713e12bc682ca364e62f9d69bcd44598c50a8a9 Mon Sep 17 00:00:00 2001
From: Juri Lelli
Date: Thu, 11 Feb 2016 16:55:49 +
Subject: [PAT
On 11/02/16 13:40, Luca Abeni wrote:
> On Thu, 11 Feb 2016 12:27:54 +
> Juri Lelli wrote:
>
> > On 11/02/16 13:22, Luca Abeni wrote:
> > > Hi Juri,
> > >
> > > On Thu, 11 Feb 2016 12:12:57 +
> > > Juri Lelli wrote:
> > >
On 11/02/16 13:22, Luca Abeni wrote:
> Hi Juri,
>
> On Thu, 11 Feb 2016 12:12:57 +0000
> Juri Lelli wrote:
> [...]
> > I think we still have (at least) two problems:
> >
> > - select_task_rq_dl, if we select a different target
> > - select_task_rq m
Hi Peter,
On 11/02/16 12:59, Peter Zijlstra wrote:
> On Tue, Feb 09, 2016 at 05:02:33PM -0800, Steve Muckle wrote:
> > > Index: linux-pm/kernel/sched/deadline.c
> > > ===
> > > --- linux-pm.orig/kernel/sched/deadline.c
> > > +++ linux
On 10/02/16 16:27, Juri Lelli wrote:
> On 10/02/16 09:37, Steven Rostedt wrote:
> > On Wed, 10 Feb 2016 11:32:58 +
> > Juri Lelli wrote:
> >
[...]
> >
> > I applied this patch and patch 2 and hit this:
> >
[...]
> >
> > It's the
: DL replenish lagged too much\n");
> dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
> dl_se->runtime = pi_se->dl_runtime;
> }
>
Acked-by: Juri Lelli
:)
Best,
- Juri
On 10/02/16 09:37, Steven Rostedt wrote:
> On Wed, 10 Feb 2016 11:32:58 +
> Juri Lelli wrote:
>
> > Hi,
> >
> > I've updated this patch since, with a bit more testing and talking with
> > Luca in private, I realized that the previous version didn'
On 10/02/16 16:46, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 3:46 PM, Juri Lelli wrote:
> > On 10/02/16 15:26, Rafael J. Wysocki wrote:
> >> On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli wrote:
> >> > On 10/02/16 14:23, Rafael J. Wysocki wrote:
> >
On 10/02/16 15:26, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli wrote:
> > On 10/02/16 14:23, Rafael J. Wysocki wrote:
> >> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli wrote:
> >> > Hi Rafael,
> >> >
> &g
On 09/02/16 15:54, Dietmar Eggemann wrote:
> On 05/02/16 09:30, Juri Lelli wrote:
> > On 04/02/16 16:46, Vincent Guittot wrote:
> >> On 4 February 2016 at 16:44, Vincent Guittot
> >> wrote:
> >>> On 4 February 2016 at 15:13, Juri Lelli wrote:
> >
On 10/02/16 14:23, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli wrote:
> > Hi Rafael,
> >
> > On 09/02/16 21:05, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> >> +/**
> >> + * cpufreq_update_util - Take a no
On 10/02/16 13:48, Luca Abeni wrote:
> Hi,
>
> On Wed, 10 Feb 2016 11:32:58 +0000
> Juri Lelli wrote:
> [...]
> > From 62f70ca3051672dce209e8355cf5eddc9d825c2a Mon Sep 17 00:00:00 2001
> > From: Juri Lelli
> > Date: Sat, 6 Feb 2016 12:41:09 +
> > Subje
Hi Rafael,
On 09/02/16 21:05, Rafael J. Wysocki wrote:
[...]
> +/**
> + * cpufreq_update_util - Take a note about CPU utilization changes.
> + * @util: Current utilization.
> + * @max: Utilization ceiling.
> + *
> + * This function is called by the scheduler on every invocation of
> + * update_l
On 10/02/16 12:43, Luca Abeni wrote:
> Hi all,
>
Hi Luca,
> On Wed, 10 Feb 2016 11:32:58 +0000
> Juri Lelli wrote:
> [...]
> > @@ -2445,14 +2445,18 @@ static int dl_overflow(struct task_struct *p,
> > int policy, if (dl_policy(policy) && !task_has_dl_poli
fix the
problem with root domains.
Best,
- Juri
--->8---
>From 62f70ca3051672dce209e8355cf5eddc9d825c2a Mon Sep 17 00:00:00 2001
From: Juri Lelli
Date: Sat, 6 Feb 2016 12:41:09 +
Subject: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth
Currently SCHED_DEADL
On 09/02/16 09:30, Steve Muckle wrote:
> On 02/09/2016 02:37 AM, Juri Lelli wrote:
> >> I'm still concerned that there's no way to obtain optimal boot time on a
> >> > heterogeneous system. Either the dynamic benchmarking is enabled, adding
> >> > 1
Hi Steve,
On 08/02/16 15:59, Steve Muckle wrote:
> Hi Juri,
>
> On 02/03/2016 03:59 AM, Juri Lelli wrote:
> > v1: DT + sysfs [1]
> >
> > v2: Dynamic profiling at boot [2]
> >
> > Third version of this patchset proposes what seems to be the soluti
Hi,
On 08/02/16 18:24, Viresh Kumar wrote:
> On 08-02-16, 18:21, Shilpasri G Bhat wrote:
> > Hi,
> >
> > On 02/08/2016 05:09 PM, Viresh Kumar wrote:
> > > Hi Rafael,
> > >
> > > Things look much much better now. I have rebased this series over
> > > pm/bleeding-edge, that has all your patches.
>
domains
reconfiguration.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Reported-by: Wanpeng Li
Reported-by: Steven Rostedt
Signed-off-by: Juri Lelli
---
kernel/sched/deadline.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 2480cab..925814e
Signed-off-by: Juri Lelli
---
kernel/sched/core.c | 2 ++
kernel/sched/deadline.c | 18 ++
kernel/sched/sched.h| 22 ++
3 files changed, 42 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 24fcdbf..706ca23 100644
--- a/kernel
don't cover with the bandwidth tracking.
Testing and feedback is more than welcome.
Best,
- Juri
[1] https://lkml.org/lkml/2016/2/3/966
Juri Lelli (2):
sched/deadline: add per rq tracking of admitted bandwidth
sched/deadline: rq_{online,offline}_dl for root_domain changes
kernel/sc
Hi,
On 05/02/16 17:19, Dietmar Eggemann wrote:
> Hi Juri,
>
> On 03/02/16 11:59, Juri Lelli wrote:
> > Add a sysfs cpu_capacity attribute with which it is possible to read and
> > write (thus over-writing default values) CPUs capacity. This might be
> > useful in situ
801 - 900 of 1334 matches
Mail list logo
