Hi Kame, 2011/3/31 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>: > Âc) Should we provide a auto memory cgroup for file caches ? > Â Â (Then we can implement a file-cache-limit.) > Âc) AFAIK, some other OSs have this kind of feature, a box for file-cache. > Â Â Because file-cache is a shared object between all cgroups, it's difficult > Â Â to handle. It may be better to have a auto cgroup for file caches and add knobs > Â Â for memcg. I have been thinking about this idea. It seems the root cause of current difficult is the whole cgroup infrastructure is based on process groups, so its counters naturally center on process. However, this is not nature for counters of file caches, which center on inodes/devs actually. This brought many confusing problems - e.g. who should be charged for a (dirty)file page? I think the answer is no process but the filesystem/block device it sits on. How about we change the view, from centering on process to centering on filesystem/device. Let's call it 'pcgroup'. When it enables, we can set limits for each filesystem/device, and charge the filesystem/device for each page seat on it. This 'pcgroup' would be orthogonal to cgroup.memcontroler. We could make cgroup.memcontroler only account/control the anon pages they have, leave all file-backend pages controlled by the 'pcgroup'. For the implementation, 'pcgroup' can reuse the struct page_cgroup - and res_counter maybe even the hierarchy reclaim code, and so on - it looks like a cgroup very much - which might make things easier. One problem is this 'pcgroup' may not be able to be implemented inside cgroup frame, as the very core code of cgroup assumes that all its controls/res_counters are per-process(group). Is this doable? Thanks, Zhu Yanhai -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href