On Thu, Oct 09, 2014 at 04:58:22PM +0800, Fam Zheng wrote:
> On Wed, 10/08 11:05, Benoît Canet wrote:
> > On Wed, Oct 08, 2014 at 02:53:38PM +0800, Fam Zheng wrote:
> > >
> > > Does this mean that after this series, all the throttle_states must be
> > > contained inside its own throttle group? If
On Wed, 10/08 11:05, Benoît Canet wrote:
> On Wed, Oct 08, 2014 at 02:53:38PM +0800, Fam Zheng wrote:
> >
> > Does this mean that after this series, all the throttle_states must be
> > contained inside its own throttle group? If so, we could embed ThrottleGroup
> > fields in ThrottleState.
> >
>
On Wed, Oct 08, 2014 at 02:53:38PM +0800, Fam Zheng wrote:
>
> Does this mean that after this series, all the throttle_states must be
> contained inside its own throttle group? If so, we could embed ThrottleGroup
> fields in ThrottleState.
>
> It's weird when a function called throttle_group_comp
On Tue, 10/07 15:24, Benoît Canet wrote:
> The throttle group support use a cooperative round robin scheduling algorithm.
>
> The principle of the algorithm are simple:
s/principle/principles/
> - Each BDS of the group is used as a token in a circular way.
> - The active BDS compute if a wait mu
The throttle group support use a cooperative round robin scheduling algorithm.
The principle of the algorithm are simple:
- Each BDS of the group is used as a token in a circular way.
- The active BDS compute if a wait must be done and arm the right timer.
- If a wait must be done the token timer
