On Thu, Mar 31, 2011 at 2:15 AM, Zhu Yanhai <zhu.yanhai@xxxxxxxxx> wrote: > 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. 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@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