Hi, On Fri, Nov 04, 2016 at 04:24:25PM +0800, Zhao Hui Ding wrote: > Hello, > > I'm Zhaohui from IBM Spectrum LSF development team. I got below message > when running LSF on SUSE11.4, so I would like to share our use scenario > and ask for the suggestions without using memory.force_empty. > > memory.force_empty is deprecated and will be removed. Let us know if it is > needed in your usecase at linux-mm@xxxxxxxxx > > LSF is a batch workload scheduler, it uses cgroup to do batch jobs > resource enforcement and accounting. For each job, LSF creates a cgroup > directory and put job's PIDs to the cgroup. > > When we implement LSF cgroup integration, we found creating a new cgroup > is much slower than renaming an existing cgroup, it's about hundreds of > milliseconds vs less than 10 milliseconds. Cgroup creation/deletion is not expected to be an ultra-hot path, but I'm surprised it takes longer than actually reclaiming leftover pages. By the time the jobs conclude, how much is usually left in the group? That said, is it even necessary to pro-actively remove the leftover cache from the group before starting the next job? Why not leave it for the next job to reclaim it lazily should memory pressure arise? It's easy to reclaim page cache, and the first to go as it's behind the next job's memory on the LRU list. -- 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>