* Michal Hocko <mhocko@xxxxxxx> [2011-03-30 10:18:53]: > On Tue 29-03-11 21:23:10, Balbir Singh wrote: > > On 03/28/11 16:33, KAMEZAWA Hiroyuki wrote: > > > On Mon, 28 Mar 2011 11:39:57 +0200 > > > Michal Hocko <mhocko@xxxxxxx> wrote: > [...] > > > Isn't it the same result with the case where no cgroup is used ? > > > What is the problem ? > > > Why it's not a problem of configuration ? > > > IIUC, you can put all logins to some cgroup by using cgroupd/libgcgroup. > > > > > > > I agree with Kame, I am still at loss in terms of understand the use > > case, I should probably see the rest of the patches > > OK, it looks that I am really bad at explaining the usecase. Let's try > it again then (hopefully in a better way). > > Consider a service which serves requests based on the in-memory > precomputed or preprocessed data. > Let's assume that getting data into memory is rather costly operation > which considerably increases latency of the request processing. Memory > access can be considered random from the system POV because we never > know which requests will come from outside. > This workflow will benefit from having the memory resident as long as > and as much as possible because we have higher chances to be used more > often and so the initial costs would pay off. > Why is mlock not the right thing to do here? Well, if the memory would > be locked and the working set would grow (again this depends on the > incoming requests) then the application would have to unlock some > portions of the memory or to risk OOM because it basically cannot > overcommit. > On the other hand, if the memory is not mlocked and there is a global > memory pressure we can have some part of the costly memory swapped or > paged out which will increase requests latencies. If the application is > placed into an isolated cgroup, though, the global (or other cgroups) > activity doesn't influence its cgroup thus the working set of the > application. I think one important aspect is what percentage of the memory needs to be isolated/locked? If you expect really large parts, then we are in trouble, unless we are aware of the exact requirements for memory and know what else will run on the system. > If we compare that to mlock we will benefit from per-group reclaim when > we get over the limit (or soft limit). So we do not start evicting the > memory unless somebody makes really pressure on the _application_. > Cgroup limits would, of course, need to be selected carefully. > > There might be other examples when simply kernel cannot know which > memory is important for the process and the long unused memory is not > the ideal choice. > There are other watermark based approaches that would work better, given that memory management is already complicated by topology, zones and we have non-reclaimable memory being used in the kernel on behalf of applications. I am not ruling out a solution, just sharing ideas. NOTE: In the longer run, we want to account for kernel usage and look at potential reclaim of slab pages. -- Three Cheers, Balbir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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>