On 02/01/2012 04:55 AM, KAMEZAWA Hiroyuki wrote:
Hi, I guess we have some topics on memory cgroups.
1-4 : someone has an implemanation
5 : no implemenation.
1. page_cgroup diet
memory cgroup uses 'struct page_cgroup', it was 40bytes per 4096bytes in past.
Johannes removed ->page and ->lru from page_cgroup, then now,
sizeof(page_cgroup)==16. Now, I'm working on removing ->flags to make
sizeof(page_cgroup)==8.
Then, finally, page_cgroup can be moved into struct page on 64bit system ?
How 32bit system will be ?
2. memory reclaim
Johannes, Michal and Ying, ant others, are now working on memory reclaim problem
with new LRU. Under it, LRU is per-memcg-per-zone.
Following topics are discussed now.
- simplificaiton/re-implemenation of softlimit
- isolation of workload (by softlimit)
- when we should stop memory reclaim, especially under direct-reclaim.
(Now, we scan all zonelist..)
3. per-memcg-lru-zone-lru-lock
I hear Hugh Dickins have some patches and are testing it.
It will be good to discuss this if it has Pros. and Cons or implemenation issue.
4. dirty ratio
In the last year, patches were posted but not merged. I'd like to hear
works on this area.
5. accounting other than user pages.
Last year, tcp buffer limiting was added to "memcg".
I was about to correct you about "last year", when suddenly my mind went
"oh god, this is 2012!"
If someone has other plans, I'd like to hear.
I myself don't think 'generic kernel memory limitation' is a good thing....
admins can't predict performance.
Can we make accounting on dentry/inode into memcg and call shrink_slab() ?
But I guess per-zone-shrink-slab() should go 1st...
Well, I have work in progress to continue that. There are a couple of
slabs I'd like to track. I am convinced that a generic framework is a
good thing, but indeed, I am still not sure if a generic interface is.
The advantage of keeping it unified, is that it prevents the number of
knobs from exploding. For us, this is not that much of a problem,
because there are only a couple of ones we are interested in. dcache and
inode is an example of that: when we sent out some proposals (that
didn't use memcg), some people wanted to see inode, not dcache being
tracked. We disagreed. But yet, the truth remains that only *one* of
them needs to be tracked, because they live in a close relation to each
other. So if we manage to find a couple of slabs that are key to that,
we can limit only those.
Well, that was food for thought only. I do think this is a nice topic.
Also, there is no serious implementation for that, as you mentioned, but
a series of patches were sent out for appreciation last year. So there
is at least a basis for starting
--
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>