On Wed, 30 Jul 2008 10:17:19 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Jul 2008 01:16:17 +0100 (BST) > Hugh Dickins <[EMAIL PROTECTED]> wrote: > > > On Tue, 29 Jul 2008, KAMEZAWA Hiroyuki wrote: > > > On Fri, 25 Jul 2008 17:46:45 +0100 (BST) > > > Hugh Dickins <[EMAIL PROTECTED]> wrote: > > > > > > > IIRC Rik expressed the same by pointing out that a cgroup at its > > > > swap limit would then be forced to grow in mem (until it hits its > > > > mem limit): so controlling the less precious resource would increase > > > > pressure on the more precious resource. (Actually, that probably > > > > bears little relation to what he said - sorry, Rik!) I don't recall > > > > what answer he got, perhaps I'd be persuaded if I heard it again. > > > > > > > Added Nishimura to CC. > > > > > > IMHO, from user point of view, both of > > > - having 2 controls as mem controller + swap controller > > > - mem + swap controller > > > doesn't have much difference. The users will use as they like. > > > > I'm not suggesting either one of those alternatives. > > > > I'm suggesting we have a mem controller (the thing we already have) > > and a mem+swap controller (which we don't yet have: a controller > > for the total mem+swap of a cgroup); the mem+swap controller likely > > making use of much that is in the mem controller, as Paul has said. > > > Ah, what mem+swap controller means is limitiing mem+swap by 'a' limit ? > It's a choice for me. From view of global LRU management, it's better. > If we can avoid an accident that the swap is fully used by some silly program, > anything is ok to me. > Hmm. mem+swap controller means a shrink to memory resource controller (try_to_free_mem_cgroup_pages()) should drop only file caches. (Because kick-out-to-swap will never changes the usage.) right ? only global-lru can make a swap. maybe I can add optimization to do this. Hmm. I should see how OOM works under some situation. Thanks, -Kame _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel