On Wed, 22 Apr 2009 12:22:41 +0200
Andrea Righi <righi.andrea@xxxxxxxxx> wrote:
> Actually I was proposing something quite similar, if I've understood
> well. Just add a hook in balance_dirty_pages() to throttle tasks in
> cgroups that exhausted their IO BW.
>
> The way to do so will be similar to the per-bdi write throttling, taking
> in account the IO requests previously submitted per cgroup, the pages
> dirtied per cgroup (considering that are not necessarily dirtied by the
> owner of the page) and apply something like congestion_wait() to
> throttle the tasks in the cgroups that exceeded the BW limit.
>
> Maybe we can just introduce cgroup_dirty_limit() simply replicating what
> we're doing for task_dirty_limit(), but using per cgroup statistics of
> course.
>
> I can change the io-throttle controller to do so. This feature should be
> valid also for the proportional BW approach.
>
> BTW Vivek's proposal to also dispatch IO requests according to cgroup
> proportional BW limits can be still valid and it is worth to be tested
> IMHO. But we must also find a way to say to the right cgroup: hey! stop
> to waste the memory with dirty pages, because you've directly or
> indirectly generated too much IO in the system and I'm throttling and/or
> not scheduling your IO requests.
>
> Objections?
>
No objections. plz let me know my following understanding is right.
1. dirty_ratio should be supported per cgroup.
- Memory cgroup should support dirty_ratio or dirty_ratio cgroup should be implemented.
For doing this, we can make use of page_cgroup.
One good point of dirty-ratio cgroup is that dirty-ratio accounting is done
against a cgroup which made pages dirty not against a owner of the page. But
if dirty_ratio cgroup is completely independent from mem_cgroup, it cannot
be a help for memory reclaiming.
Then,
- memcg itself should have dirty_ratio check.
- like bdi/task_dirty_limit(), a cgroup (which is not memcg) can be used
another filter for dirty_ratio.
2. dirty_ratio is not I/O BW control.
3. I/O BW(limit) control cgroup should be implemented and it should be exsiting
in I/O scheduling layer or somewhere around. But it's not easy.
4. To track bufferred I/O, we have to add "tag" to pages which tell us who
generated the I/O. Now it's called blockio-cgroup and implementation details
are still under discussion.
So, current status is.
A. memcg should support dirty_ratio for its own memory reclaim.
in plan.
B. another cgroup can be implemnted to support cgroup_dirty_limit().
But relationship with "A" should be discussed.
no plan yet.
C. I/O cgroup and bufferred I/O tracking system.
Now under patch review.
And this I/O throttle is mainly for "C" discussion.
Right ?
-Kame
Regards,
-Kame
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
