>> Removing cpu_load completely certainly makes things simpler, my worry is
>> just how much was lost by doing it. I agree that cpu_load needs a
>> cleanup, but I can't convince myself that just removing it completely
>> and not having any longer term view of cpu load anymore is without any
>> neg
On 18 February 2014 13:05, Morten Rasmussen wrote:
> On Mon, Feb 17, 2014 at 01:55:06AM +, Alex Shi wrote:
>> The cpu_load decays on time according past cpu load of rq. The sched_avg
>> also decays tasks' load on time. Now we has 2 kind decay for cpu_load. That
>> is a kind of redundancy. An
On 02/18/2014 02:03 PM, Alex Shi wrote:
[snip]
>>
>
> I reviewed my patch again. Also didn't find suspicious line for the
> following rcu stall. Will wait for your report. :)
Posted, it will be triggered in pure tip/master, your patch set was
innocent ;-)
Regards,
Michael Wang
>>
>
--
To uns
On 02/18/2014 12:52 PM, Michael wang wrote:
> On 02/17/2014 09:55 AM, Alex Shi wrote:
>> The cpu_load decays on time according past cpu load of rq. The sched_avg
>> also decays tasks' load on time. Now we has 2 kind decay for cpu_load. That
>> is a kind of redundancy. And increase the system load
On 02/17/2014 09:55 AM, Alex Shi wrote:
> The cpu_load decays on time according past cpu load of rq. The sched_avg also
> decays tasks' load on time. Now we has 2 kind decay for cpu_load. That is a
> kind of redundancy. And increase the system load by decay calculation. This
> patch try to remov
On 02/17/2014 09:55 AM, Alex Shi wrote:
> The cpu_load decays on time according past cpu load of rq. The sched_avg also
> decays tasks' load on time. Now we has 2 kind decay for cpu_load. That is a
> kind of redundancy. And increase the system load by decay calculation. This
> patch try to remov
6 matches
Mail list logo
