OpenVZ Forum - RDF feed
type: channel
items: Re: [RFC/PATCH] cgroup swap subsystem

Re: [RFC/PATCH] cgroup swap subsystem
type: item
description: Daisuke Nishimura wrote: > Hi. > > Even if limiting memory usage by cgroup memory subsystem > or isolating memory by cpuset, swap space is shared, so > resource isolation is not enough. If one group uses up all the > swap space, it can affect other groups. > > I try making a patch of swap subsystem based on memory > subsystem, which limits swap usage per cgroup. > It can now charge and limit the swap usage. > > I implemented this feature as a new subsystem, > not as a part of memory subsystem, because I don't want to > make big change to memcontrol.c, and even if implemented > as other subsystem, users can manage memory and swap on > the same cgroup directory if mount them together. > > Basic idea of my implementation: > - what will be charged ? > the number of swap entries. This is a very obscure thing "a swap entry" for the end user. People would prefer accounting bytes. > - when to charge/uncharge ? > charge at get_swap_entry(), and uncharge at swap_entry_free(). > > - to what group charge the swap entry ? > To determine to what swap_cgroup (corresponding to mem_cgroup in > memory subsystem) the swap entry should be charged, > I added a pointer to mm_struct to page_cgroup(pc->pc_mm), and > changed the argument of get_swap_entry() from (void) to > (struct page *). As a result, get_swap_entry() can determine > to what swap_cgroup it should charge the swap entry > by referring to page->page_cgroup->mm_struct->swap_cgroup. > > - from what group uncharge the swap entry ? > I added to swap_info_struct a member 'struct swap_cgroup **', > array of pointer to which swap_cgroup the swap entry is > charged. > > Todo: > - rebase new kernel, and split into some patches. > - Merge with memory subsystem (if it would be better), or > remove dependency on CONFIG_CGROUP_MEM_CONT if possible > (needs to make page_cgroup more generic one). Merge is a must IMHO. I can hardly imagine a situation in which someone would need these two separately. > - More tests, cleanups, and feartures …
creator: Pavel Emelianov
date: 2008-03-05T08:33:38-00:00

Re: [RFC/PATCH] cgroup swap subsystem
type: item
description: Hi. >> @@ -664,6 +665,10 @@ retry: >> pc->flags = PAGE_CGROUP_FLAG_ACTIVE; >> if (ctype == MEM_CGROUP_CHARGE_TYPE_CACHE) >> pc->flags |= PAGE_CGROUP_FLAG_CACHE; >> +#ifdef CONFIG_CGROUP_SWAP_LIMIT >> + atomic_inc(&mm->mm_count); >> + pc->pc_mm = mm; >> +#endif > > What kernel is this patch for? I cannot find this code in 2.6.25-rc3-mm1 > For linux-2.6.24-mm1. Thanks, Daisuke Nishimura. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Daisuke Nishimura
date: 2008-03-05T08:51:22-00:00

Re: [RFC/PATCH] cgroup swap subsystem
type: item
description: On Wed, 5 Mar 2008, Pavel Emelyanov wrote: > Daisuke Nishimura wrote: > > > > Todo: > > - rebase new kernel, and split into some patches. > > - Merge with memory subsystem (if it would be better), or > > remove dependency on CONFIG_CGROUP_MEM_CONT if possible > > (needs to make page_cgroup more generic one). > > Merge is a must IMHO. I can hardly imagine a situation in which > someone would need these two separately. Strongly agree. Nobody's interested in swap as such: it's just secondary memory, where RAM is primary memory. People want to control memory as the sum of the two; and I expect they may also want to control primary memory (all that the current memcg does) within that. I wonder if such nesting of limits fits easily into cgroups or will be problematic. Hugh _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Hugh Dickins
date: 2008-03-05T14:07:07-00:00

Re: [RFC/PATCH] cgroup swap subsystem
type: item
description: Hugh Dickins wrote: > On Wed, 5 Mar 2008, Pavel Emelyanov wrote: >> Daisuke Nishimura wrote: >>> Todo: >>> - rebase new kernel, and split into some patches. >>> - Merge with memory subsystem (if it would be better), or >>> remove dependency on CONFIG_CGROUP_MEM_CONT if possible >>> (needs to make page_cgroup more generic one). >> Merge is a must IMHO. I can hardly imagine a situation in which >> someone would need these two separately. > > Strongly agree. Nobody's interested in swap as such: it's just > secondary memory, where RAM is primary memory. People want to > control memory as the sum of the two; and I expect they may also > want to control primary memory (all that the current memcg does) > within that. I wonder if such nesting of limits fits easily > into cgroups or will be problematic. This nesting would affect the res_couter abstraction, not the cgroup infrastructure. Current design of resource counters doesn't allow for such thing, but the extension is a couple-of-lines patch :) > Hugh > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2008-03-05T14:14:12-00:00

Re: [RFC/PATCH] cgroup swap subsystem
type: item
description: On Wed, 05 Mar 2008 17:14:12 +0300 Pavel Emelyanov <xemul@openvz.org> wrote: > > Strongly agree. Nobody's interested in swap as such: it's just > > secondary memory, where RAM is primary memory. People want to > > control memory as the sum of the two; and I expect they may also > > want to control primary memory (all that the current memcg does) > > within that. I wonder if such nesting of limits fits easily > > into cgroups or will be problematic. > > This nesting would affect the res_couter abstraction, not the > cgroup infrastructure. Current design of resource counters doesn't > allow for such thing, but the extension is a couple-of-lines patch :) > IMHO, keeping res_counter simple is better. Is this kind of new entry in mem_cgroup not good ? == struct mem_cgroup { ... struct res_counter memory_limit. struct res_counter swap_limit. .. } _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2008-03-06T00:33:15-00:00

Re: [RFC/PATCH] cgroup swap subsystem
type: item
description: On Wed, Mar 5, 2008 at 4:33 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > Is this kind of new entry in mem_cgroup not good ? > == > struct mem_cgroup { > ... > struct res_counter memory_limit. > struct res_counter swap_limit. > .. I agree with this - main memory and swap memory are rather different kinds of resources, with very different performance characteristics. It should be possible to control them completely independently (e.g. this job gets 100M of main memory, and doesn't swap at all). Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2008-03-06T00:35:43-00:00

Re: [RFC/PATCH] cgroup swap subsystem
type: item
description: KAMEZAWA Hiroyuki wrote: > On Wed, 05 Mar 2008 17:14:12 +0300 > Pavel Emelyanov <xemul@openvz.org> wrote: >>> Strongly agree. Nobody's interested in swap as such: it's just >>> secondary memory, where RAM is primary memory. People want to >>> control memory as the sum of the two; and I expect they may also >>> want to control primary memory (all that the current memcg does) >>> within that. I wonder if such nesting of limits fits easily >>> into cgroups or will be problematic. >> This nesting would affect the res_couter abstraction, not the >> cgroup infrastructure. Current design of resource counters doesn't >> allow for such thing, but the extension is a couple-of-lines patch :) >> > IMHO, keeping res_counter simple is better. > > Is this kind of new entry in mem_cgroup not good ? > == > struct mem_cgroup { > ... > struct res_counter memory_limit. > struct res_counter swap_limit. > .. > } I meant the same thing actually. By "nesting would affect" I meant, that we might want to make res_counters hierarchical. That would kill two birds with one stone - we will make a true hierarchical memory accounting and let charging of two counters with one call. > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2008-03-06T08:20:17-00:00