(2012/06/09 8:06), Andrew Morton wrote:
On Wed, 30 May 2012 20:13:31 +0530
"Aneesh Kumar K.V"<aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote:
- code: seperating hugetlb bits out from memcg bits to avoid growing
mm/memcontrol.c beyond its current 5650 lines, and
I can definitely look at spliting mm/memcontrol.c
- performance: not incurring any overhead of enabling memcg for per-
page tracking that is unnecessary if users only want to limit hugetlb
pages.
Since Andrew didn't sent the patchset to Linus because of this
discussion, I looked at reworking the patchset as a seperate
controller. The patchset I sent here
http://thread.gmane.org/gmane.linux.kernel.mm/79230
have seen minimal testing. I also folded the fixup patches
Andrew had in -mm to original patchset.
Let me know if the changes looks good.
This is starting to be a problem. I'm still sitting on the old version
of this patchset and it will start to get in the way of other work.
We now have this new version of the patchset which implements a
separate controller but it is unclear to me which way we want to go.
Can the memcg developers please drop everything else and make a
decision here?
Following is a summary in my point of view.
I think there are several topics.
- overheads.
(A) IMHO, runtime overhead will be negligible because...
- if hugetlb is used, anonymous memory accouning doesn't add much overheads
because they're not used.
- when it comes to file-cache accounting, I/O dominates performance rather
than memcg..
- but you may see some overheads with 100+ cpu system...I'm not sure.
(B) memory space overhead will not be negligible.
- now, memcg uses 16bytes per page....4GB/1TB.
This may be an obvious overhead to the system if working set size are
quite big and the apps want to use huge size memory.
(C) what hugetlbfs is.
- hugetlb is statically allocated. So, they're not usual memory.
Then, hugetlb cgroup is better.
- IMHO, hugetlb is memory. And I thought memory.limit_in_bytes should
take it into account....
(D) code duplication
- memory cgroup and hugetlb cgroup will have similar hooks,codes,UIs.
- we need some #ifdef if we have consolidated memory/hugetlb cgroup.
(E) user experience
- with independent hugetlb cgroup, users can disable memory cgroup.
- with consolidated memcg+hugetlb cgroup, we'll be able to limit
usual page + hugetlb usage by a limit.
Now, I think...
1. I need to agree that overhead is _not_ negligible.
2. THP should be the way rather than hugetlb for my main target platform.
(shmem/tmpfs should support THP. we need study.)
user-experience should be fixed by THP+tmpfs+memcg.
3. It seems Aneesh decided to have independent hugetlb cgroup.
So, now, I admit to have independent hugetlb cgroup.
Other opinions ?
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/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>