[Devel] Re: [patch 1/4] io controller: documentation
KAMEZAWA Hiroyuki
kamezawa.hiroyu at jp.fujitsu.com
Thu Nov 6 18:32:09 PST 2008
On Thu, 06 Nov 2008 10:30:23 -0500
vgoyal at redhat.com wrote:
> +ISSUES
> +======
> +- IO controller can buffer the bios if suffcient tokens were not available
> + at the time of bio submission. Once the tokens are available, these bios
> + are dispatched to elevator/lower layers in first come first serve manner.
> + And this has potential to break CFQ where a RT tasks should be able to
> + dispatch the bio first or a high priority task should be able to release
> + more bio as compared to low priority task in same cgroup.
> +
> + Not sure how to fix it. May be we need to maintain another rb-tree and
> + keep track of RT tasks and tasks priorities and dispatch accordingly. This
> + is equivalent of duplicating lots of CFQ logic and not sure how would it
> + impact AS behaviour.
>
Why you don't isolate RT tasks into other cgroup ?
/cgroup/bio-cgroup/group_for_usual/...usual tasks.
/group_for_RT/ ...RT tasks. you can use high-speed path.
How about adding RT flag to bio-cgroup and skip buffering at bio-cgroup if RT
flag is set ? I think handling an usual process and RT process in "a" cgroup
just makes the code complex.
Looking into a cpu-scheduler, which is the first module handling RT, it has
some tweaks to handle RT in the system.
- special RT scheduler.
- isolated RT domain
- maximum execution time allowed to RT
....
Maybe handling RT in following way is usual way...(if we do something in this layer)
- Allow RT-bio-cgroup to skip limit check.
- But RT-bio-cgroup calculates io-throuput, execution time, statistics...
- When RT tasks in RT-bio-cgroup does excessive I/O which starves the whole system
too long, raise safeguard-limitter. and tell users Warning or kill it.
Hmm ?
Thanks,
-Kame
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list