Hi, I would like to attend this year (2015) LSF/MM conference. I am particularly interested in the MM track. I would like to discuss (among other topics already suggested) the following topics: General MM topics: - THP success rate has become one of the metric for reclaim/compaction changes which I feel is missing one important aspect and that is cost/benefit analysis. It might be better to have more THP pages in some loads but the whole advantage might easily go away when the initial cost is higher than all aggregated saves. When it comes to benchmarks and numbers we are usually missing the later. This becomes even more an issue with memcg when close to the limit. Does it make sense to do a heavy reclaim (with THP size target) to fulfill THP allocations? If not memcg acts against the global MM and ruins the effort, on the other hand reclaiming 512 pages can take quite some time. The memcg part could be worked around by either precharging THP pages or reclaiming only clean page cache pages which would handle most usecases IMO but it would be better to think about a !memcg solution. Do we really want to allocate THP pages unconditionally or rather build them up if it seems worthwhile? - As it turned out recently GFP_KERNEL mimicing GFP_NOFAIL for !costly allocation is sometimes kicking us back because we are basically creating an invisible lock dependencies which might livelock the whole system under OOM conditions. That leads to attempts to add more hacks into the OOM killer which is tricky enough as is. Changing the current state is quite risky because we do not really know how many places in the kernel silently depend on this behavior. As per Johannes attempt (http://marc.info/?l=linux-mm&m=141932770811346) it is clear that we are not yet there! I do not have very good ideas how to deal with this unfortunatelly... And as a memcg co-maintainer I would like to also discuss the following topics. - We should finally settle down with a set of core knobs exported with the new unified hierarchy cgroups API. I have proposed this already http://marc.info/?l=linux-mm&m=140552160325228&w=2 but there is no clear consensus and the discussion has died later on. I feel it would be more productive to sit together and come up with a reasonable compromise between - let's start from the begining and keep useful and reasonable features. - kmem accounting is seeing a lot of activity mainly thanks to Vladimir. He is basically the only active developer in this area. I would be happy if he can attend as well and discuss his future plans in the area. The work overlaps with slab allocators and slab shrinkers so having people familiar with these areas would be more than welcome -- Michal Hocko SUSE Labs -- 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>