On Sat, 11 Feb 2012 03:06:40 +0530 "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > Hi, > > This patchset implements a cgroup resource controller for HugeTLB pages. > It is similar to the existing hugetlb quota support in that the limit is > enforced at mmap(2) time and not at fault time. HugeTLB quota limit the > number of huge pages that can be allocated per superblock. > > For shared mapping we track the region mapped by a task along with the > hugetlb cgroup in inode region list. We keep the hugetlb cgroup charged > even after the task that did mmap(2) exit. The uncharge happens during > file truncate. For Private mapping we charge and uncharge from the current > task cgroup. > Hm, Could you provide an Documenation/cgroup/hugetlb.txt at RFC ? It makes clear what your patch does. I wonder whether this should be under memory cgroup or not. In the 1st design of cgroup, I think it was considered one-feature-one-subsystem was good. But in recent discussion, I tend to hear that's hard to use. Now, memory cgroup has memory.xxxxx for controlling anon/file memory.memsw.xxxx for controlling memory+swap memory.kmem.tcp_xxxx for tcp controlling. How about memory.hugetlb.xxxxx ? > The current patchset doesn't support cgroup hierarchy. We also don't > allow task migration across cgroup. What happens when a user destroys a cgroup which contains alive hugetlb pages ? Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>