On Fri, Jul 26, 2013 at 2:50 PM, Peter Zijlstra wrote:
> On Fri, Jul 26, 2013 at 02:24:50PM -0700, Paul Turner wrote:
>> On Fri, Jul 26, 2013 at 2:03 PM, Peter Zijlstra wrote:
>> >
>> >
>> > OK, so I have the below; however on a second look, Paul, shouldn't that
>> > update_cfs_shares() call be
On Fri, Jul 26, 2013 at 02:24:50PM -0700, Paul Turner wrote:
> On Fri, Jul 26, 2013 at 2:03 PM, Peter Zijlstra wrote:
> >
> >
> > OK, so I have the below; however on a second look, Paul, shouldn't that
> > update_cfs_shares() call be in entity_tick(), right after calling
> >
On Fri, Jul 26, 2013 at 2:03 PM, Peter Zijlstra wrote:
>
>
> OK, so I have the below; however on a second look, Paul, shouldn't that
> update_cfs_shares() call be in entity_tick(), right after calling
> update_cfs_rq_blocked_load(). Because placing it in
> update_cfs_rq_blocked_load() means its
OK, so I have the below; however on a second look, Paul, shouldn't that
update_cfs_shares() call be in entity_tick(), right after calling
update_cfs_rq_blocked_load(). Because placing it in
update_cfs_rq_blocked_load() means its now called twice on the
enqueue/dequeue paths through:
>> Ah I see what's happening. Currently we only call update_cfs_shares()
>> from the enqueue/dequeue paths. However since your tasks never sleep and
>> cannot migrate they never pass this code. This in turns means that the
>> inter-cgroup relations (the shares) don't get updated.
>>
>> I think
[Moving to LKML]
Max sent in the following (best ever) bug report:
On Wed, Jul 24, 2013 at 8:41 AM, Max Hailperin wrote:
> [1.] One line summary of the problem:
> Persistent unfair sharing of a processor by auto groups in 3.11-rc2 (has
> twice regressed)
>
> [2.] Full description of the
[Moving to LKML]
Max sent in the following (best ever) bug report:
On Wed, Jul 24, 2013 at 8:41 AM, Max Hailperin m...@gustavus.edu wrote:
[1.] One line summary of the problem:
Persistent unfair sharing of a processor by auto groups in 3.11-rc2 (has
twice regressed)
[2.] Full description of
Ah I see what's happening. Currently we only call update_cfs_shares()
from the enqueue/dequeue paths. However since your tasks never sleep and
cannot migrate they never pass this code. This in turns means that the
inter-cgroup relations (the shares) don't get updated.
I think your patch
OK, so I have the below; however on a second look, Paul, shouldn't that
update_cfs_shares() call be in entity_tick(), right after calling
update_cfs_rq_blocked_load(). Because placing it in
update_cfs_rq_blocked_load() means its now called twice on the
enqueue/dequeue paths through:
On Fri, Jul 26, 2013 at 2:03 PM, Peter Zijlstra pet...@infradead.org wrote:
OK, so I have the below; however on a second look, Paul, shouldn't that
update_cfs_shares() call be in entity_tick(), right after calling
update_cfs_rq_blocked_load(). Because placing it in
On Fri, Jul 26, 2013 at 02:24:50PM -0700, Paul Turner wrote:
On Fri, Jul 26, 2013 at 2:03 PM, Peter Zijlstra pet...@infradead.org wrote:
OK, so I have the below; however on a second look, Paul, shouldn't that
update_cfs_shares() call be in entity_tick(), right after calling
On Fri, Jul 26, 2013 at 2:50 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jul 26, 2013 at 02:24:50PM -0700, Paul Turner wrote:
On Fri, Jul 26, 2013 at 2:03 PM, Peter Zijlstra pet...@infradead.org wrote:
OK, so I have the below; however on a second look, Paul, shouldn't that
12 matches
Mail list logo
