On Mon, 2013-02-25 at 17:53 +0800, Alex Shi wrote:
> On 02/25/2013 11:23 AM, Mike Galbraith wrote:
> > On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote:
> >
> >> One of problem is the how to decide the criteria of the burst? If we set
> >> 5 waking up/ms is burst, we will lose 4 waking up/ms.
>
On 02/25/2013 11:23 AM, Mike Galbraith wrote:
> On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote:
>
>> One of problem is the how to decide the criteria of the burst? If we set
>> 5 waking up/ms is burst, we will lose 4 waking up/ms.
>> another problem is the burst detection cost, we need
On 02/25/2013 11:23 AM, Mike Galbraith wrote:
On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote:
One of problem is the how to decide the criteria of the burst? If we set
5 waking up/ms is burst, we will lose 4 waking up/ms.
another problem is the burst detection cost, we need tracking a
On Mon, 2013-02-25 at 17:53 +0800, Alex Shi wrote:
On 02/25/2013 11:23 AM, Mike Galbraith wrote:
On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote:
One of problem is the how to decide the criteria of the burst? If we set
5 waking up/ms is burst, we will lose 4 waking up/ms.
another
On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote:
> One of problem is the how to decide the criteria of the burst? If we set
> 5 waking up/ms is burst, we will lose 4 waking up/ms.
> another problem is the burst detection cost, we need tracking a period
> history info of the waking up, better on
On 02/25/2013 01:51 AM, Preeti U Murthy wrote:
> Hi,
>
> On 02/24/2013 02:57 PM, Alex Shi wrote:
>> On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
>>> On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
> The name is a secondary issue, first you need to explain why you
think
>
Hi,
On 02/24/2013 02:57 PM, Alex Shi wrote:
> On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
>> On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
The name is a secondary issue, first you need to explain why you
>>> think
nr_running is a useful metric at all.
You can have a
>> Um, let me try to explain again, The utilisation need much time to
>> accumulate itself(345ms). Whenever with or without load weight, many
>> bursting tasks just give a minimum weight to the carrier CPU at the
>> first few ms. So, it is too easy to do a incorrect distribution here and
>> need
Hi Alex,
On 02/24/2013 02:57 PM, Alex Shi wrote:
> On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
>> On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
The name is a secondary issue, first you need to explain why you
>>> think
nr_running is a useful metric at all.
You can have
On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
> On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
>>> The name is a secondary issue, first you need to explain why you
>> think
>>> nr_running is a useful metric at all.
>>>
>>> You can have a high nr_running and a low utilization (a burst of
>>>
On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
The name is a secondary issue, first you need to explain why you
think
nr_running is a useful metric at all.
You can have a high nr_running and a low utilization (a burst of
wakeups, each waking
Hi Alex,
On 02/24/2013 02:57 PM, Alex Shi wrote:
On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
The name is a secondary issue, first you need to explain why you
think
nr_running is a useful metric at all.
You can have a high nr_running and
Um, let me try to explain again, The utilisation need much time to
accumulate itself(345ms). Whenever with or without load weight, many
bursting tasks just give a minimum weight to the carrier CPU at the
first few ms. So, it is too easy to do a incorrect distribution here and
need migration
Hi,
On 02/24/2013 02:57 PM, Alex Shi wrote:
On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
The name is a secondary issue, first you need to explain why you
think
nr_running is a useful metric at all.
You can have a high nr_running and a low
On 02/25/2013 01:51 AM, Preeti U Murthy wrote:
Hi,
On 02/24/2013 02:57 PM, Alex Shi wrote:
On 02/22/2013 04:54 PM, Peter Zijlstra wrote:
On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
The name is a secondary issue, first you need to explain why you
think
nr_running is a useful metric
On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote:
One of problem is the how to decide the criteria of the burst? If we set
5 waking up/ms is burst, we will lose 4 waking up/ms.
another problem is the burst detection cost, we need tracking a period
history info of the waking up, better on
On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
> > The name is a secondary issue, first you need to explain why you
> think
> > nr_running is a useful metric at all.
> >
> > You can have a high nr_running and a low utilization (a burst of
> > wakeups, each waking a process that'll instantly
On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote:
The name is a secondary issue, first you need to explain why you
think
nr_running is a useful metric at all.
You can have a high nr_running and a low utilization (a burst of
wakeups, each waking a process that'll instantly go to sleep
On 02/21/2013 09:33 PM, Peter Zijlstra wrote:
> On Wed, 2013-02-20 at 22:23 +0800, Alex Shi wrote:
>>> But but but,... nr_running is completely unrelated to utilization.
>>>
>>
>> Actually, I also hesitated on the name, how about using nr_running to
>> replace group_util directly?
>
>
> The name
On Wed, 2013-02-20 at 22:23 +0800, Alex Shi wrote:
> > But but but,... nr_running is completely unrelated to utilization.
> >
>
> Actually, I also hesitated on the name, how about using nr_running to
> replace group_util directly?
The name is a secondary issue, first you need to explain why
On Wed, 2013-02-20 at 22:23 +0800, Alex Shi wrote:
But but but,... nr_running is completely unrelated to utilization.
Actually, I also hesitated on the name, how about using nr_running to
replace group_util directly?
The name is a secondary issue, first you need to explain why you think
On 02/21/2013 09:33 PM, Peter Zijlstra wrote:
On Wed, 2013-02-20 at 22:23 +0800, Alex Shi wrote:
But but but,... nr_running is completely unrelated to utilization.
Actually, I also hesitated on the name, how about using nr_running to
replace group_util directly?
The name is a secondary
On 02/20/2013 09:36 PM, Peter Zijlstra wrote:
> On Wed, 2013-02-20 at 20:09 +0800, Alex Shi wrote:
>> On 02/20/2013 05:42 PM, Peter Zijlstra wrote:
>>> On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
+/*
+ * Try to collect the task running number and capacity of the group.
+ */
On Wed, 2013-02-20 at 20:09 +0800, Alex Shi wrote:
> On 02/20/2013 05:42 PM, Peter Zijlstra wrote:
> > On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
> >> +/*
> >> + * Try to collect the task running number and capacity of the group.
> >> + */
> >> +static void get_sg_power_stats(struct
On 02/20/2013 05:42 PM, Peter Zijlstra wrote:
> On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
>> +/*
>> + * Try to collect the task running number and capacity of the group.
>> + */
>> +static void get_sg_power_stats(struct sched_group *group,
>> + struct sched_domain *sd, struct
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
> +/*
> + * Try to collect the task running number and capacity of the group.
> + */
> +static void get_sg_power_stats(struct sched_group *group,
> + struct sched_domain *sd, struct sg_lb_stats *sgs)
> +{
> + int i;
> +
> +
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
+/*
+ * Try to collect the task running number and capacity of the group.
+ */
+static void get_sg_power_stats(struct sched_group *group,
+ struct sched_domain *sd, struct sg_lb_stats *sgs)
+{
+ int i;
+
+
On 02/20/2013 05:42 PM, Peter Zijlstra wrote:
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
+/*
+ * Try to collect the task running number and capacity of the group.
+ */
+static void get_sg_power_stats(struct sched_group *group,
+ struct sched_domain *sd, struct sg_lb_stats *sgs)
On Wed, 2013-02-20 at 20:09 +0800, Alex Shi wrote:
On 02/20/2013 05:42 PM, Peter Zijlstra wrote:
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
+/*
+ * Try to collect the task running number and capacity of the group.
+ */
+static void get_sg_power_stats(struct sched_group *group,
On 02/20/2013 09:36 PM, Peter Zijlstra wrote:
On Wed, 2013-02-20 at 20:09 +0800, Alex Shi wrote:
On 02/20/2013 05:42 PM, Peter Zijlstra wrote:
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
+/*
+ * Try to collect the task running number and capacity of the group.
+ */
+static void
This patch add power aware scheduling in fork/exec/wake. It try to
select cpu from the busiest while still has utilization group. That's
will save power since it leaves more groups idle in system.
The trade off is adding a power aware statistics collection in group
seeking. But since the
This patch add power aware scheduling in fork/exec/wake. It try to
select cpu from the busiest while still has utilization group. That's
will save power since it leaves more groups idle in system.
The trade off is adding a power aware statistics collection in group
seeking. But since the
32 matches
Mail list logo
