On Wed, Jan 08, 2014 at 01:32:57PM +, Peter Zijlstra wrote:
> On Wed, Jan 08, 2014 at 01:27:39PM +, Morten Rasmussen wrote:
> > On Wed, Jan 08, 2014 at 12:45:34PM +, Peter Zijlstra wrote:
> > > On Wed, Jan 08, 2014 at 12:35:34PM +, Morten Rasmussen wrote:
> > > > > Currently we dete
On Wed, Jan 08, 2014 at 01:04:07PM +, Peter Zijlstra wrote:
> On Wed, Jan 08, 2014 at 12:52:28PM +, Morten Rasmussen wrote:
>
> > If I remember correctly, Alex used the rq runnable_avg_sum (in rq->avg)
> > for this. It is the most obvious choice, but it takes ages to reach
> > 100%.
> >
>
On Wed, Jan 08, 2014 at 01:27:39PM +, Morten Rasmussen wrote:
> On Wed, Jan 08, 2014 at 12:45:34PM +, Peter Zijlstra wrote:
> > On Wed, Jan 08, 2014 at 12:35:34PM +, Morten Rasmussen wrote:
> > > > Currently we detect overload by sg.nr_running >= sg.capacity, which can
> > > > be very m
On Wed, Jan 08, 2014 at 12:45:34PM +, Peter Zijlstra wrote:
> On Wed, Jan 08, 2014 at 12:35:34PM +, Morten Rasmussen wrote:
> > > Currently we detect overload by sg.nr_running >= sg.capacity, which can
> > > be very misleading because while a cpu might have a task running 'now'
> > > it mig
On Wed, Jan 08, 2014 at 12:52:28PM +, Morten Rasmussen wrote:
> If I remember correctly, Alex used the rq runnable_avg_sum (in rq->avg)
> for this. It is the most obvious choice, but it takes ages to reach
> 100%.
>
> #define LOAD_AVG_MAX_N 345
>
> Worst case it takes 345 ms from the system
On Wed, Jan 08, 2014 at 08:37:16AM +, Peter Zijlstra wrote:
> On Wed, Jan 08, 2014 at 04:32:18PM +0800, Alex Shi wrote:
> > In my old power aware scheduling patchset, I had tried the 95 to 99. But
> > all those values will lead imbalance when we test while(1) like cases.
> > like in a 24LCPUs g
On Wed, Jan 08, 2014 at 12:35:34PM +, Morten Rasmussen wrote:
> > Currently we detect overload by sg.nr_running >= sg.capacity, which can
> > be very misleading because while a cpu might have a task running 'now'
> > it might be 99% idle.
> >
> > At which point I argued we should change the ca
On Wed, Jan 08, 2014 at 12:35:34PM +, Morten Rasmussen wrote:
> > The harder case is where all 3 tasks are of equal weight; in which case
> > fairness would mandate we (slowly) rotate the tasks such that they all
> > get 2/3 time -- we also horribly fail at this :-)
>
> I have encountered that
On Tue, Jan 07, 2014 at 08:49:51PM +, Peter Zijlstra wrote:
> On Tue, Jan 07, 2014 at 03:41:54PM +, Morten Rasmussen wrote:
> > I think that could work if we sort of the priority scaling issue that I
> > mentioned before.
>
> We talked a bit about this on IRC a month or so ago, right? My m
On 01/07/2014 11:37 PM, Morten Rasmussen wrote:
>>> > >
>>> > > So something like:
>>> > >
>>> > > avg = runnable + p(i) * blocked; where p(i) \e [0,1]
>>> > >
>>> > > could maybe be used to replace the cpu_load array and still represent
>>> > > the concept of looking at a bigger picture for larg
On Wed, Jan 08, 2014 at 04:32:18PM +0800, Alex Shi wrote:
> In my old power aware scheduling patchset, I had tried the 95 to 99. But
> all those values will lead imbalance when we test while(1) like cases.
> like in a 24LCPUs groups, 24*5% > 1. So, finally use 100% as overload
> indicator. And in t
On 01/08/2014 04:49 AM, Peter Zijlstra wrote:
> On Tue, Jan 07, 2014 at 03:41:54PM +, Morten Rasmussen wrote:
>> I think that could work if we sort of the priority scaling issue that I
>> mentioned before.
>
> We talked a bit about this on IRC a month or so ago, right? My memories
> from that
On Tue, Jan 07, 2014 at 03:41:54PM +, Morten Rasmussen wrote:
> I think that could work if we sort of the priority scaling issue that I
> mentioned before.
We talked a bit about this on IRC a month or so ago, right? My memories
from that are that your main complaint is that we don't detect the
On 01/07/2014 06:01 PM, Vincent Guittot wrote:
> On 7 January 2014 11:39, Preeti U Murthy wrote:
>> On 01/07/2014 03:20 PM, Peter Zijlstra wrote:
>>> On Tue, Jan 07, 2014 at 03:10:21PM +0530, Preeti U Murthy wrote:
What if we want to add arch specific flags to the NUMA domain? Currently
On 01/07/2014 04:43 PM, Peter Zijlstra wrote:
> On Tue, Jan 07, 2014 at 04:09:39PM +0530, Preeti U Murthy wrote:
>> On 01/07/2014 03:20 PM, Peter Zijlstra wrote:
>>> On Tue, Jan 07, 2014 at 03:10:21PM +0530, Preeti U Murthy wrote:
What if we want to add arch specific flags to the NUMA domain?
On Tue, Jan 07, 2014 at 02:10:59PM +, Peter Zijlstra wrote:
> On Tue, Jan 07, 2014 at 02:22:20PM +0100, Peter Zijlstra wrote:
>
> I just realized there's two different p's in there.
>
> > Ah, another way of looking at it is that the avg without blocked
> > component is a 'now' picture. It is
On Tue, Jan 07, 2014 at 02:11:22PM +, Vincent Guittot wrote:
> On 7 January 2014 14:22, Peter Zijlstra wrote:
> > On Tue, Jan 07, 2014 at 09:32:04AM +0100, Vincent Guittot wrote:
> >> On 6 January 2014 17:31, Peter Zijlstra wrote:
> >> > On Mon, Jan 06, 2014 at 02:41:31PM +0100, Vincent Guitt
On 7 January 2014 14:22, Peter Zijlstra wrote:
> On Tue, Jan 07, 2014 at 09:32:04AM +0100, Vincent Guittot wrote:
>> On 6 January 2014 17:31, Peter Zijlstra wrote:
>> > On Mon, Jan 06, 2014 at 02:41:31PM +0100, Vincent Guittot wrote:
>> >> IMHO, these settings will disappear sooner or later, as a
On Tue, Jan 07, 2014 at 02:22:20PM +0100, Peter Zijlstra wrote:
I just realized there's two different p's in there.
> Ah, another way of looking at it is that the avg without blocked
> component is a 'now' picture. It is the load we are concerned with right
> now.
>
> The more blocked we add the
On Tue, Jan 07, 2014 at 09:32:04AM +0100, Vincent Guittot wrote:
> On 6 January 2014 17:31, Peter Zijlstra wrote:
> > On Mon, Jan 06, 2014 at 02:41:31PM +0100, Vincent Guittot wrote:
> >> IMHO, these settings will disappear sooner or later, as an example the
> >> idle/busy _idx are going to be rem
On 1 January 2014 06:00, Preeti U Murthy wrote:
> Hi Vincent,
>
> On 12/18/2013 06:43 PM, Vincent Guittot wrote:
>> This patch applies on top of the two patches [1][2] that have been proposed
>> by
>> Peter for creating a new way to initialize sched_domain. It includes some
>> minor
>> compilati
On 7 January 2014 11:39, Preeti U Murthy wrote:
> On 01/07/2014 03:20 PM, Peter Zijlstra wrote:
>> On Tue, Jan 07, 2014 at 03:10:21PM +0530, Preeti U Murthy wrote:
>>> What if we want to add arch specific flags to the NUMA domain? Currently
>>> with Peter's patch:https://lkml.org/lkml/2013/11/5/23
On Tue, Jan 07, 2014 at 10:39:39AM +, Preeti U Murthy wrote:
> On 01/07/2014 03:20 PM, Peter Zijlstra wrote:
> > On Tue, Jan 07, 2014 at 03:10:21PM +0530, Preeti U Murthy wrote:
> >> What if we want to add arch specific flags to the NUMA domain? Currently
> >> with Peter's patch:https://lkml.or
On Tue, Jan 07, 2014 at 04:09:39PM +0530, Preeti U Murthy wrote:
> On 01/07/2014 03:20 PM, Peter Zijlstra wrote:
> > On Tue, Jan 07, 2014 at 03:10:21PM +0530, Preeti U Murthy wrote:
> >> What if we want to add arch specific flags to the NUMA domain? Currently
> >> with Peter's patch:https://lkml.or
On 01/07/2014 03:20 PM, Peter Zijlstra wrote:
> On Tue, Jan 07, 2014 at 03:10:21PM +0530, Preeti U Murthy wrote:
>> What if we want to add arch specific flags to the NUMA domain? Currently
>> with Peter's patch:https://lkml.org/lkml/2013/11/5/239 and this patch,
>> the arch can modify the sd flags
On Mon, Jan 06, 2014 at 05:15:30PM +, Morten Rasmussen wrote:
> Is there any examples of frequency domains not matching the span of a
> sched_domain?
nafaik, but I don't really know much about this anyway.
> I would have thought that we would have a matching sched_domain to hang
> the P and C
On Tue, Jan 07, 2014 at 03:10:21PM +0530, Preeti U Murthy wrote:
> What if we want to add arch specific flags to the NUMA domain? Currently
> with Peter's patch:https://lkml.org/lkml/2013/11/5/239 and this patch,
> the arch can modify the sd flags of the topology levels till just before
> the NUMA
Hi Vincent, Peter,
On 12/18/2013 06:43 PM, Vincent Guittot wrote:
> This patch applies on top of the two patches [1][2] that have been proposed by
> Peter for creating a new way to initialize sched_domain. It includes some
> minor
> compilation fixes and a trial of using this new method on ARM pl
On 6 January 2014 17:31, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 02:41:31PM +0100, Vincent Guittot wrote:
>> IMHO, these settings will disappear sooner or later, as an example the
>> idle/busy _idx are going to be removed by Alex's patch.
>
> Well I'm still entirely unconvinced by them..
>
On 6 January 2014 17:21, Peter Zijlstra wrote:
> On Wed, Dec 18, 2013 at 02:13:51PM +0100, Vincent Guittot wrote:
>> This patch applies on top of the two patches [1][2] that have been proposed
>> by
>> Peter for creating a new way to initialize sched_domain. It includes some
>> minor
>> compilat
On Mon, Jan 06, 2014 at 04:28:13PM +, Peter Zijlstra wrote:
> On Mon, Dec 23, 2013 at 06:22:17PM +0100, Dietmar Eggemann wrote:
> > I'm not sure if the idea to create a dedicated sched_domain level for every
> > topology flag representing a specific functionality will scale. From the
> > perspe
AFAICT this is a chicken-egg problem, the OS never did anything useful
with it so the hardware guys are now trying to do something with it, but
this also means that if we cannot predict what the hardware will do
under certain circumstances the OS really cannot do anything smart
anymore.
So yes,
On Mon, Jan 06, 2014 at 05:48:38PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 08:37:13AM -0800, Arjan van de Ven wrote:
> > On 1/6/2014 8:33 AM, Peter Zijlstra wrote:
> > >On Wed, Jan 01, 2014 at 10:30:33AM +0530, Preeti U Murthy wrote:
> > >>The design looks good to me. In my opinion i
On Mon, Jan 06, 2014 at 08:37:13AM -0800, Arjan van de Ven wrote:
> On 1/6/2014 8:33 AM, Peter Zijlstra wrote:
> >On Wed, Jan 01, 2014 at 10:30:33AM +0530, Preeti U Murthy wrote:
> >>The design looks good to me. In my opinion information like P-states and
> >>C-states dependency can be kept separat
On 1/6/2014 8:33 AM, Peter Zijlstra wrote:
On Wed, Jan 01, 2014 at 10:30:33AM +0530, Preeti U Murthy wrote:
The design looks good to me. In my opinion information like P-states and
C-states dependency can be kept separate from the topology levels, it
might get too complicated unless the informat
On Wed, Jan 01, 2014 at 10:30:33AM +0530, Preeti U Murthy wrote:
> The design looks good to me. In my opinion information like P-states and
> C-states dependency can be kept separate from the topology levels, it
> might get too complicated unless the information is tightly coupled to
> the topology
On Wed, Dec 18, 2013 at 02:13:51PM +0100, Vincent Guittot wrote:
> This patch applies on top of the two patches [1][2] that have been proposed by
> Peter for creating a new way to initialize sched_domain. It includes some
> minor
> compilation fixes and a trial of using this new method on ARM plat
On Mon, Dec 23, 2013 at 06:22:17PM +0100, Dietmar Eggemann wrote:
> I'm not sure if the idea to create a dedicated sched_domain level for every
> topology flag representing a specific functionality will scale. From the
> perspective of energy-aware scheduling we need e.g. energy costs (P and C
> st
On Mon, Jan 06, 2014 at 02:41:31PM +0100, Vincent Guittot wrote:
> IMHO, these settings will disappear sooner or later, as an example the
> idle/busy _idx are going to be removed by Alex's patch.
Well I'm still entirely unconvinced by them..
removing the cpu_load array makes sense, but I'm starti
On 23 December 2013 18:22, Dietmar Eggemann wrote:
> Hi Vincent,
>
>
> On 18/12/13 14:13, Vincent Guittot wrote:
>>
>> This patch applies on top of the two patches [1][2] that have been
>> proposed by
>> Peter for creating a new way to initialize sched_domain. It includes some
>> minor
>> compilat
Hi Vincent,
On 12/18/2013 06:43 PM, Vincent Guittot wrote:
> This patch applies on top of the two patches [1][2] that have been proposed by
> Peter for creating a new way to initialize sched_domain. It includes some
> minor
> compilation fixes and a trial of using this new method on ARM platform.
Hi Vincent,
On 18/12/13 14:13, Vincent Guittot wrote:
This patch applies on top of the two patches [1][2] that have been proposed by
Peter for creating a new way to initialize sched_domain. It includes some minor
compilation fixes and a trial of using this new method on ARM platform.
[1] https:/
This patch applies on top of the two patches [1][2] that have been proposed by
Peter for creating a new way to initialize sched_domain. It includes some minor
compilation fixes and a trial of using this new method on ARM platform.
[1] https://lkml.org/lkml/2013/11/5/239
[2] https://lkml.org/lkml/20
43 matches
Mail list logo
