On Thu, 14 Apr 2011, KAMEZAWA Hiroyuki wrote:
> > I'm wondering if we can just modify count_vm_event() directly for
> > CONFIG_CGROUP_MEM_RES_CTLR so that we automatically track all vmstat items
> > (those in enum vm_event_item) for each memcg. We could add an array of
> > NR_VM_EVENT_ITEMS into each struct mem_cgroup to be incremented on
> > count_vm_event() for current's memcg.
> >
> > If that's done, we wouldn't have to add additional calls for every vmstat
> > item we want to duplicate from the global counters.
> >
>
> Maybe we do that finally.
>
> For now, IIUC, over 50% of VM_EVENTS are needless for memcg (ex. per zone stats)
> and this array consumes large size of percpu area. I think we need to select
> events carefully even if we do that. And current memcg's percpu stat is mixture
> of vm_events and vm_stat. We may need to sort out them and re-design it.
> My concern is that I'm not sure we have enough percpu area for vmstat+vmevents
> for 1000+ memcg, and it's allowed even if we can do.
>
What I proposed above was adding an array directly into struct mem_cgroup
so that we don't collect the stats percpu, they are incremented directly
in the mem_cgroup. Perhaps if we separated enum vm_event_item out into
two separate arrays (those useful only globally and those useful for both
global and memcg), then this would be simple.
Something like
enum vm_event_item {
PGPGIN,
PGPGOUT,
PSWPIN,
PSWPOUT,
...
NR_VM_EVENT_ITEMS,
};
enum vm_global_event_item {
KSWAPD_STEAL = NR_VM_EVENT_ITEMS,
KSWAPD_INODESTEAL,
...
};
and then in count_vm_event(), check
if (item < NR_VM_EVENT_ITEMS) {
memcg_add_vm_event(mem, item, count);
}
I don't think we need to be concerned about reordering the global
/proc/vmstat to fit this purpose.
--
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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>