(2013/02/05 21:35), Michal Hocko wrote:
Hi, I would like to discuss the following topics:
I missed the deadline :(
* memcg oom should be more sensitive to locked contexts because now it is possible that a task is sitting in mem_cgroup_handle_oom holding some other lock (e.g. i_mutex or mmap_sem) up the chain which might block other task to terminate on OOM so we basically end up in a deadlock. Almost all memcg charges happen from the page fault path where we can retry but one class of them happen from add_to_page_cache_locked and that is a bit more problematic.
Yes, this is a topic should be discussed.
* memcg doesn't use PF_MEMALLOC for the targeted reclaim code paths which asks for stack overflows (and we have already seen those - e.g. from the xfs pageout paths). The primary problem to use the flag is that there is no dirty pages throttling and writeback kicked out for memcg so if we didn't writeback from the reclaim the caller could be blocked for ever. Memcg dirty accounting is shaping slowly so we should start thinking about the writeback as well.
Sure.
* While we are at the memcg dirty pages accounting (https://lkml.org/lkml/2012/12/25/95). It turned out that the locking is really nasty (https://lkml.org/lkml/2013/1/2/48). The locking should be reworked without incurring any penalty on the fast path. This sounds really challenging.
I'd like to fix the locking problem.
* I would really like to finally settle down on something wrt. soft limit reclaim. I am pretty sure Ying would like to discuss this topic as well so I will not go into details about it. I will post what I have before the conference so that we can discuss her approach and what was the primary disagreement the last time. I can go into more ditails as a follow up if people are interested of course. * Finally I would like to collect feedback for the mm git tree.
Other points related to memcg is ... + kernel memory accounting + per-zone-per-memcg inode/dentry caching. Glaubler tries to account inode/dentry in kmem controller. To do that, I think inode and dentry should be hanldled per zone, at first. IIUC, there are ongoing work but not merged yet. + overheads by memcg Mel explained memcg's big overheads last year's MM summit. AFAIK, we have not made any progress with that. If someone have detailed data, please share again... 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>