On Thu, May 31, 2007 at 02:15:34AM -0700, William Lee Irwin III wrote:
> Yes, the larger number of schedulable entities and hence slower
> convergence to groupwise weightings is a disadvantage of the flattening.
> A hybrid scheme seems reasonable enough.
Cool! This puts me back on track to
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
>> Its ->wait_runtime will drop less significantly, which lets it be
>> inserted in rb-tree much to the left of those 1000 tasks (and which
>> indirectly lets it gain back its fair share during subsequent
>> schedule cycles).
>>
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
> Its ->wait_runtime will drop less significantly, which lets it be
> inserted in rb-tree much to the left of those 1000 tasks (and which indirectly
> lets it gain back its fair share during subsequent schedule cycles).
>
> Hmm
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
>> Temporarily, yes. All this only works when averaged out.
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
> So essentially when we calculate delta_mine component for each of those
> 1000 tasks, we will
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
> On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
> > Hmm ..the fact that each task runs for a minimum of 1 tick seems to
> > complicate the matters to me (when doing group fairness given a single
> > level
On Wed, May 30, 2007 at 09:09:26PM -0700, William Lee Irwin III wrote:
>> It's not all that tricky.
On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
> Hmm ..the fact that each task runs for a minimum of 1 tick seems to
> complicate the matters to me (when doing group fairness
On Wed, May 30, 2007 at 09:09:26PM -0700, William Lee Irwin III wrote:
It's not all that tricky.
On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
Hmm ..the fact that each task runs for a minimum of 1 tick seems to
complicate the matters to me (when doing group fairness
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
Hmm ..the fact that each task runs for a minimum of 1 tick seems to
complicate the matters to me (when doing group fairness given a single
level
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
Temporarily, yes. All this only works when averaged out.
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
So essentially when we calculate delta_mine component for each of those
1000 tasks, we will find
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
Its -wait_runtime will drop less significantly, which lets it be
inserted in rb-tree much to the left of those 1000 tasks (and which indirectly
lets it gain back its fair share during subsequent schedule cycles).
Hmm ..is
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
Its -wait_runtime will drop less significantly, which lets it be
inserted in rb-tree much to the left of those 1000 tasks (and which
indirectly lets it gain back its fair share during subsequent
schedule cycles).
Hmm ..is
On Thu, May 31, 2007 at 02:15:34AM -0700, William Lee Irwin III wrote:
Yes, the larger number of schedulable entities and hence slower
convergence to groupwise weightings is a disadvantage of the flattening.
A hybrid scheme seems reasonable enough.
Cool! This puts me back on track to
On Wed, May 30, 2007 at 09:09:26PM -0700, William Lee Irwin III wrote:
> It's not all that tricky.
Hmm ..the fact that each task runs for a minimum of 1 tick seems to
complicate the matters to me (when doing group fairness given a single
level hierarchy). A user with 1000 (or more) tasks can be
On Wed, May 30, 2007 at 01:13:59PM -0700, William Lee Irwin III wrote:
>> The step beyond was to show how nice numbers can be done with all that
>> hierarchical task grouping so they have global effects instead of
>> effects limited to the scope of the narrowest grouping hierarchy
>> containing
On Wed, May 30, 2007 at 01:13:59PM -0700, William Lee Irwin III wrote:
> On Wed, May 30, 2007 at 10:44:05PM +0530, Srivatsa Vaddagiri wrote:
> > Hmm ..so do you think this weight decomposition can be used to flatten
> > the tree all the way to a single level in case of cfs? That would mean we
> >
On Sat, May 26, 2007 at 08:41:12AM -0700, William Lee Irwin III wrote:
>> The smpnice affair is better phrased in terms of task weighting. It's
>> simple to honor nice in such an arrangement. First unravel the
>> grouping hierarchy, then weight by nice. This looks like
[...]
>> conveniently
On Sat, May 26, 2007 at 08:41:12AM -0700, William Lee Irwin III wrote:
> The smpnice affair is better phrased in terms of task weighting. It's
> simple to honor nice in such an arrangement. First unravel the
> grouping hierarchy, then weight by nice. This looks like
>
> tasknicehier1
On Sat, May 26, 2007 at 08:41:12AM -0700, William Lee Irwin III wrote:
The smpnice affair is better phrased in terms of task weighting. It's
simple to honor nice in such an arrangement. First unravel the
grouping hierarchy, then weight by nice. This looks like
[...]
conveniently collapse to
On Wed, May 30, 2007 at 01:13:59PM -0700, William Lee Irwin III wrote:
On Wed, May 30, 2007 at 10:44:05PM +0530, Srivatsa Vaddagiri wrote:
Hmm ..so do you think this weight decomposition can be used to flatten
the tree all the way to a single level in case of cfs? That would mean we
can
On Wed, May 30, 2007 at 01:13:59PM -0700, William Lee Irwin III wrote:
The step beyond was to show how nice numbers can be done with all that
hierarchical task grouping so they have global effects instead of
effects limited to the scope of the narrowest grouping hierarchy
containing the task.
On Wed, May 30, 2007 at 09:09:26PM -0700, William Lee Irwin III wrote:
It's not all that tricky.
Hmm ..the fact that each task runs for a minimum of 1 tick seems to
complicate the matters to me (when doing group fairness given a single
level hierarchy). A user with 1000 (or more) tasks can be
On Sat, May 26, 2007 at 08:41:12AM -0700, William Lee Irwin III wrote:
The smpnice affair is better phrased in terms of task weighting. It's
simple to honor nice in such an arrangement. First unravel the
grouping hierarchy, then weight by nice. This looks like
tasknicehier1 hier2
William Lee Irwin III wrote:
On Wed, May 30, 2007 at 10:09:28AM +1000, Peter Williams wrote:
So what you're saying is that you think dynamic priority (or its
equivalent) should be used for load balancing instead of static priority?
It doesn't do much in other schemes, but when fairness is
On Mon, May 28, 2007 at 10:09:19PM +0530, Srivatsa Vaddagiri wrote:
> What do these task weights control? Timeslice primarily? If so, I am not
> sure how well it can co-exist with cfs then (unless you are planning to
> replace cfs with a equally good interactive/fair scheduler :)
> I would be very
William Lee Irwin III wrote:
>> Lag is the deviation of a task's allocated CPU time from the CPU time
>> it would be granted by the ideal fair scheduling algorithm (generalized
>> processor sharing; take the limit of RR with per-task timeslices
>> proportional to load weight as the scale factor
On Mon, May 28, 2007 at 10:09:19PM +0530, Srivatsa Vaddagiri wrote:
> On Fri, May 25, 2007 at 10:14:58AM -0700, Li, Tong N wrote:
> > is represented by a weight of 10. Inside the group, let's say the two
> > tasks, P1 and P2, have weights 1 and 2. Then the system-wide weight for
> > P1 is 10/3 and
William Lee Irwin III wrote:
William Lee Irwin III wrote:
Lag should be considered in lieu of load because lag
On Sun, May 27, 2007 at 11:29:51AM +1000, Peter Williams wrote:
What's the definition of lag here?
Lag is the deviation of a task's allocated CPU time from the CPU time
it would
William Lee Irwin III wrote:
>> Lag should be considered in lieu of load because lag
On Sun, May 27, 2007 at 11:29:51AM +1000, Peter Williams wrote:
> What's the definition of lag here?
Lag is the deviation of a task's allocated CPU time from the CPU time
it would be granted by the ideal fair
William Lee Irwin III wrote:
Lag should be considered in lieu of load because lag
On Sun, May 27, 2007 at 11:29:51AM +1000, Peter Williams wrote:
What's the definition of lag here?
Lag is the deviation of a task's allocated CPU time from the CPU time
it would be granted by the ideal fair
William Lee Irwin III wrote:
William Lee Irwin III wrote:
Lag should be considered in lieu of load because lag
On Sun, May 27, 2007 at 11:29:51AM +1000, Peter Williams wrote:
What's the definition of lag here?
Lag is the deviation of a task's allocated CPU time from the CPU time
it would
On Mon, May 28, 2007 at 10:09:19PM +0530, Srivatsa Vaddagiri wrote:
On Fri, May 25, 2007 at 10:14:58AM -0700, Li, Tong N wrote:
is represented by a weight of 10. Inside the group, let's say the two
tasks, P1 and P2, have weights 1 and 2. Then the system-wide weight for
P1 is 10/3 and the
William Lee Irwin III wrote:
Lag is the deviation of a task's allocated CPU time from the CPU time
it would be granted by the ideal fair scheduling algorithm (generalized
processor sharing; take the limit of RR with per-task timeslices
proportional to load weight as the scale factor approaches
On Mon, May 28, 2007 at 10:09:19PM +0530, Srivatsa Vaddagiri wrote:
What do these task weights control? Timeslice primarily? If so, I am not
sure how well it can co-exist with cfs then (unless you are planning to
replace cfs with a equally good interactive/fair scheduler :)
I would be very
William Lee Irwin III wrote:
On Wed, May 30, 2007 at 10:09:28AM +1000, Peter Williams wrote:
So what you're saying is that you think dynamic priority (or its
equivalent) should be used for load balancing instead of static priority?
It doesn't do much in other schemes, but when fairness is
Peter Williams wrote:
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the
cpu affinity of tasks is a deliberate policy action on the part of
the system administrator and has to be
On 5/28/07, Peter Williams <[EMAIL PROTECTED]> wrote:
In any case, there's no point having cpu affinity if it's going to be
ignored. Maybe you could have two levels of affinity: 1. if set by a
root it must be obeyed; and 2. if set by an ordinary user it can be
overridden if the best interests
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the cpu
affinity of tasks is a deliberate policy action on the part of the
system administrator and has to be honoured.
mmm ..but users
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
> I don't think that ignoring cpu affinity is an option. Setting the cpu
> affinity of tasks is a deliberate policy action on the part of the
> system administrator and has to be honoured.
mmm ..but users can set cpu affinity
On Fri, May 25, 2007 at 10:14:58AM -0700, Li, Tong N wrote:
> Nice work, Vatsa. When I wrote the DWRR algorithm, I flattened the
> hierarchies into one level, so maybe that approach can be applied to
> your code as well. What I did is to maintain task and task group weights
> and reservations
On Fri, May 25, 2007 at 10:14:58AM -0700, Li, Tong N wrote:
Nice work, Vatsa. When I wrote the DWRR algorithm, I flattened the
hierarchies into one level, so maybe that approach can be applied to
your code as well. What I did is to maintain task and task group weights
and reservations
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the cpu
affinity of tasks is a deliberate policy action on the part of the
system administrator and has to be honoured.
mmm ..but users can set cpu affinity w/o
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the cpu
affinity of tasks is a deliberate policy action on the part of the
system administrator and has to be honoured.
mmm ..but users
On 5/28/07, Peter Williams [EMAIL PROTECTED] wrote:
In any case, there's no point having cpu affinity if it's going to be
ignored. Maybe you could have two levels of affinity: 1. if set by a
root it must be obeyed; and 2. if set by an ordinary user it can be
overridden if the best interests of
Peter Williams wrote:
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the
cpu affinity of tasks is a deliberate policy action on the part of
the system administrator and has to be
William Lee Irwin III wrote:
Srivatsa Vaddagiri wrote:
Ingo/Peter, any thoughts here? CFS and smpnice probably is "broken"
with respect to such example as above albeit for nice-based tasks.
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
See above. I think that faced with
Srivatsa Vaddagiri wrote:
>> Ingo/Peter, any thoughts here? CFS and smpnice probably is "broken"
>> with respect to such example as above albeit for nice-based tasks.
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
> See above. I think that faced with cpu affinity use by the
Srivatsa Vaddagiri wrote:
Ingo/Peter, any thoughts here? CFS and smpnice probably is broken
with respect to such example as above albeit for nice-based tasks.
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
See above. I think that faced with cpu affinity use by the system
William Lee Irwin III wrote:
Srivatsa Vaddagiri wrote:
Ingo/Peter, any thoughts here? CFS and smpnice probably is broken
with respect to such example as above albeit for nice-based tasks.
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
See above. I think that faced with cpu
Srivatsa Vaddagiri wrote:
Good example :) USER2's single task will have to share its CPU with
USER1's 50 tasks (unless we modify the smpnice load balancer to
disregard cpu affinity that is - which I would not prefer to do).
I don't think that ignoring cpu affinity is an option. Setting the
On Fri, May 25, 2007 at 08:18:56PM +0400, Kirill Korotaev wrote:
> 2 physical CPUs can't select the same VCPU at the same time.
> i.e. VCPU can be running on 1 PCPU only at the moment.
> and vice versa: PCPU can run only 1 VCPU at the given moment.
>
> So serialization is done when we need to
On Fri, 2007-05-25 at 21:44 +0530, Srivatsa Vaddagiri wrote:
> >
> > That assumes per-user scheduling groups; other configurations would
> > make it one step for each level of hierarchy. It may be possible to
> > reduce those steps to only state transitions that change weightings
> > and
Srivatsa Vaddagiri wrote:
> On Fri, May 25, 2007 at 05:05:16PM +0400, Kirill Korotaev wrote:
>
>>>That way the scheduler would first pick a "virtual CPU" to schedule, and
>>>then pick a user from that virtual CPU, and then a task from the user.
>>
>>don't you mean the vice versa:
>>first use to
On Wed, May 23, 2007 at 11:03:16AM -0700, William Lee Irwin III wrote:
> Well, SMP load balancing is what makes all this hard.
Agreed. I am optimistic that we can achieve good degree of SMP
fairness using similar mechanism as smpnice ..
> On Wed, May 23, 2007 at 10:18:59PM +0530, Srivatsa
On Fri, May 25, 2007 at 05:05:16PM +0400, Kirill Korotaev wrote:
> > That way the scheduler would first pick a "virtual CPU" to schedule, and
> > then pick a user from that virtual CPU, and then a task from the user.
>
> don't you mean the vice versa:
> first use to scheduler, then VCPU (which
Ingo Molnar wrote:
> * Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
>
>>Can you repeat your tests with this patch pls? With the patch applied,
>>I am now getting the same split between nice 0 and nice 10 task as
>>CFS-v13 provides (90:10 as reported by top )
>>
>> 5418 guest 20 0
On Fri, May 25, 2007 at 02:05:36PM +0200, Ingo Molnar wrote:
> great. Btw., could you please keep the "up to this point there should be
> no behavioral change in CFS" fundamental splitup of your patches -
sure ..basically the changes required in CFS core is the introduction of two
structures -
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Fri, May 25, 2007 at 01:11:40PM +0200, Ingo Molnar wrote:
> > > I was planning on reusing smpnice concepts here, with the difference
> > > that we balance group weights across CPU in addition to total weight
> > > of CPUs.
> >
> > ok, that
On Fri, May 25, 2007 at 01:11:40PM +0200, Ingo Molnar wrote:
> > I was planning on reusing smpnice concepts here, with the difference
> > that we balance group weights across CPU in addition to total weight
> > of CPUs.
>
> ok, that would be (much) simpler that any explicit vcpu approach. Do
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Fri, May 25, 2007 at 10:29:51AM +0200, Ingo Molnar wrote:
> > btw., what are you thoughts about SMP?
>
> I was planning on reusing smpnice concepts here, with the difference
> that we balance group weights across CPU in addition to total
On Fri, May 25, 2007 at 10:29:51AM +0200, Ingo Molnar wrote:
> btw., what are you thoughts about SMP?
I was planning on reusing smpnice concepts here, with the difference
that we balance group weights across CPU in addition to total weight of
CPUs.
For ex, assuming weight of each task is 10
Srivatsa Vaddagiri a écrit :
Can you repeat your tests with this patch pls? With the patch applied, I am
now getting the same split between nice 0 and nice 10 task as CFS-v13
provides (90:10 as reported by top )
Yep, this fixes the problem for me too.
Thanks.
--
Guillaume
-
To unsubscribe
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> Can you repeat your tests with this patch pls? With the patch applied,
> I am now getting the same split between nice 0 and nice 10 task as
> CFS-v13 provides (90:10 as reported by top )
>
> 5418 guest 20 0 2464 304 236 R 90 0.0
On Wed, May 23, 2007 at 08:32:52PM +0200, Ingo Molnar wrote:
> > Here's an attempt to extend CFS (v13) to be fair at a group level,
> > rather than just at task level. The patch is in a very premature state
> > (passes simple tests, smp load balance not supported yet) at this
> > point. I am
On Thu, May 24, 2007 at 12:26:16AM +0200, Guillaume Chazarain wrote:
> As a sidenote, while in CFS-v13 a nice=0 tasks seems to get 10x more CPU
> than a nice=10 one, with the group fairness patch, the ratio drops to
> less than 2x (for tasks with the same UID).
gah ..silly me.
Can you repeat
On Thu, May 24, 2007 at 12:26:16AM +0200, Guillaume Chazarain wrote:
As a sidenote, while in CFS-v13 a nice=0 tasks seems to get 10x more CPU
than a nice=10 one, with the group fairness patch, the ratio drops to
less than 2x (for tasks with the same UID).
gah ..silly me.
Can you repeat your
On Wed, May 23, 2007 at 08:32:52PM +0200, Ingo Molnar wrote:
Here's an attempt to extend CFS (v13) to be fair at a group level,
rather than just at task level. The patch is in a very premature state
(passes simple tests, smp load balance not supported yet) at this
point. I am sending it
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Can you repeat your tests with this patch pls? With the patch applied,
I am now getting the same split between nice 0 and nice 10 task as
CFS-v13 provides (90:10 as reported by top )
5418 guest 20 0 2464 304 236 R 90 0.0
Srivatsa Vaddagiri a écrit :
Can you repeat your tests with this patch pls? With the patch applied, I am
now getting the same split between nice 0 and nice 10 task as CFS-v13
provides (90:10 as reported by top )
Yep, this fixes the problem for me too.
Thanks.
--
Guillaume
-
To unsubscribe
On Fri, May 25, 2007 at 01:11:40PM +0200, Ingo Molnar wrote:
I was planning on reusing smpnice concepts here, with the difference
that we balance group weights across CPU in addition to total weight
of CPUs.
ok, that would be (much) simpler that any explicit vcpu approach. Do you
plan
On Fri, May 25, 2007 at 10:29:51AM +0200, Ingo Molnar wrote:
btw., what are you thoughts about SMP?
I was planning on reusing smpnice concepts here, with the difference
that we balance group weights across CPU in addition to total weight of
CPUs.
For ex, assuming weight of each task is 10
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Fri, May 25, 2007 at 10:29:51AM +0200, Ingo Molnar wrote:
btw., what are you thoughts about SMP?
I was planning on reusing smpnice concepts here, with the difference
that we balance group weights across CPU in addition to total weight
of
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Fri, May 25, 2007 at 01:11:40PM +0200, Ingo Molnar wrote:
I was planning on reusing smpnice concepts here, with the difference
that we balance group weights across CPU in addition to total weight
of CPUs.
ok, that would be (much)
On Fri, May 25, 2007 at 02:05:36PM +0200, Ingo Molnar wrote:
great. Btw., could you please keep the up to this point there should be
no behavioral change in CFS fundamental splitup of your patches -
sure ..basically the changes required in CFS core is the introduction of two
structures -
Ingo Molnar wrote:
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Can you repeat your tests with this patch pls? With the patch applied,
I am now getting the same split between nice 0 and nice 10 task as
CFS-v13 provides (90:10 as reported by top )
5418 guest 20 0 2464 304 236 R
On Fri, May 25, 2007 at 05:05:16PM +0400, Kirill Korotaev wrote:
That way the scheduler would first pick a virtual CPU to schedule, and
then pick a user from that virtual CPU, and then a task from the user.
don't you mean the vice versa:
first use to scheduler, then VCPU (which is
On Wed, May 23, 2007 at 11:03:16AM -0700, William Lee Irwin III wrote:
Well, SMP load balancing is what makes all this hard.
Agreed. I am optimistic that we can achieve good degree of SMP
fairness using similar mechanism as smpnice ..
On Wed, May 23, 2007 at 10:18:59PM +0530, Srivatsa
Srivatsa Vaddagiri wrote:
On Fri, May 25, 2007 at 05:05:16PM +0400, Kirill Korotaev wrote:
That way the scheduler would first pick a virtual CPU to schedule, and
then pick a user from that virtual CPU, and then a task from the user.
don't you mean the vice versa:
first use to scheduler, then
On Fri, 2007-05-25 at 21:44 +0530, Srivatsa Vaddagiri wrote:
That assumes per-user scheduling groups; other configurations would
make it one step for each level of hierarchy. It may be possible to
reduce those steps to only state transitions that change weightings
and incremental
On Fri, May 25, 2007 at 08:18:56PM +0400, Kirill Korotaev wrote:
2 physical CPUs can't select the same VCPU at the same time.
i.e. VCPU can be running on 1 PCPU only at the moment.
and vice versa: PCPU can run only 1 VCPU at the given moment.
So serialization is done when we need to assign
Srivatsa Vaddagiri wrote:
Good example :) USER2's single task will have to share its CPU with
USER1's 50 tasks (unless we modify the smpnice load balancer to
disregard cpu affinity that is - which I would not prefer to do).
I don't think that ignoring cpu affinity is an option. Setting the
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> Here's an attempt to extend CFS (v13) to be fair at a group level,
> rather than just at task level. The patch is in a very premature state
> (passes simple tests, smp load balance not supported yet) at this
> point. I am sending it out early
Here's an attempt to extend CFS (v13) to be fair at a group level, rather than
just at task level. The patch is in a very premature state (passes
simple tests, smp load balance not supported yet) at this point. I am sending
it out early to know if this is a good direction to proceed.
Salient
Here's an attempt to extend CFS (v13) to be fair at a group level, rather than
just at task level. The patch is in a very premature state (passes
simple tests, smp load balance not supported yet) at this point. I am sending
it out early to know if this is a good direction to proceed.
Salient
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Here's an attempt to extend CFS (v13) to be fair at a group level,
rather than just at task level. The patch is in a very premature state
(passes simple tests, smp load balance not supported yet) at this
point. I am sending it out early to
84 matches
Mail list logo
