On 01/21/2013 10:40 AM, Preeti U Murthy wrote:
> Hi Alex,
> Thank you very much for running the below benchmark on
> blocked_load+runnable_load:) Just a few queries.
>
> How did you do the wake up balancing? Did you iterate over the L3
> package looking for an idle cpu? Or did you just query the L
Hi Alex,
Thank you very much for running the below benchmark on
blocked_load+runnable_load:) Just a few queries.
How did you do the wake up balancing? Did you iterate over the L3
package looking for an idle cpu? Or did you just query the L2 package
for an idle cpu?
I think when you are using bloc
On Sun, Jan 20, 2013 at 08:57:51AM -0600, Rob Clark wrote:
>Btw, not sure if any of you have seen the 0-day kbuild setup that intel has..
>
>https://lists.01.org/mailman/listinfo/kbuild
>
>runs various builds for different archs on every commit with different
>configs, randconfig, etc. And variou
>>> The blocked load of a cluster will be high if the blocked tasks have
>>> run recently. The contribution of a blocked task will be divided by 2
>>> each 32ms, so it means that a high blocked load will be made of recent
>>> running tasks and the long sleeping tasks will not influence the load
>>>
On 01/09/2013 11:14 AM, Preeti U Murthy wrote:
> Here comes the point of making both load balancing and wake up
> balance(select_idle_sibling) co operative. How about we always schedule
> the woken up task on the prev_cpu? This seems more sensible considering
> load balancing consid
Btw, not sure if any of you have seen the 0-day kbuild setup that intel has..
https://lists.01.org/mailman/listinfo/kbuild
runs various builds for different archs on every commit with different
configs, randconfig, etc. And various checks with sparse, smatch,
etc. Seems kinda useful, and would
