Re: [RFC][PATCH 0/8] Use EDF to throttle RT task groups

[Fabio Checconi]

> From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> Date: Wed, Jul 15, 2009 09:50:12AM +0200
>
> On Thu, 2009-07-09 at 15:51 +0200, Fabio Checconi wrote:
> 
> > I was thinking about doing things gradually: first extend throttling
> > to handle generic periods, then extend the push-pull logic (I think you
> > are referring to it with load-balancing) to fully support it, and then
> > think about global EDF.  I think it would be difficult to do all the
> > things at one time.
> 
> Agreed.
> 
> > About minimal concurrency group scheduling, I am not sure of how we
> > would handle CPUs hot insertion/extraction, or how the allocation would
> > be done efficiently (avoiding bin-packing issues) online inside the kernel.
> 
> Right, since the current interface specifies bandwidth in a single-cpu
> normalized fashion, adding/removing cpus will only affect the total
> bandwidth available, but should not affect the bandwidth calculations.
> 
> So it should not break anything, but it sure might surprise, then again,
> hotplug is an explicit action on behalf of the admin, so he pretty much
> gets what he asked for :-)
> 

Even the proper assignment of runtimes and periods is in the hands of who
runs the system, so the effectiveness of admission control already depends 
on the userspace.


> I might have to re-read that mim-concurrency G-EDF paper again, but I
> failed to spot the bin-packing issue.
> 

In the paper you cited, the Conclusion section lists the support for
dynamic systems and for joining/leaving of tasks as a future work; I
think that handling (de-)fragmentation and allocation of cpu bandwidth
when tasks and groups are created/destroyed might be quite complex from
within the kernel.

I'd prefer to have the mechanims enforcing the bandwidth allocation
inside the kernel, and, eventually, an interface allowing the userspace
to specify nontrivial allocation schemes, like the one in the paper.


> > To adapt the current load-balancer to the choices of the deadline-based
> > scheduler I was thinking about using a cpupri-like structure per task_group,
> > but now I'm not able to estimate the resulting overhead...
> 
> Right, per task_group sounds about the right level for the FIFO
> balancer. It gets a little more complicated due to having a dynamic
> number of vcpus being served at any one time though.
> 
> This will also lead to extra task migrations, but sure, whatever works
> first, then make it better.
> 

This will also be interesting to evaluate the cost of other hierarchical
global schedulers, since implementing them with partitioned queues will
require similar techniques to migrate tasks...


> > Do you think that this gradual approach makes sense?
> 
> Yeah it does ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/