Re: [LSF][MM] rough agenda for memcg.

[Michel Lespinasse <walken@google.com>]

On Thu, Mar 31, 2011 at 2:15 AM, Zhu Yanhai <zhu.yanhai@gmail.com> wrote:
> Hi Kame,
>
> 2011/3/31 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>:
>>  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.

This has been an open issue for Google as well. Greg Thelen gave this
some though last year and had a proposal around the idea of forcing
files within certain directories to be accounted to a given cgroup.
We're not actively implementing this right now, but if there is
outside interest this might be worth discussing (might just be as an
informal conversation rather than a session though).

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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=mailto:"dont@kvack.org"> email@kvack.org </a>