mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: nishimura@mxp.nes.nec.co.jp, LKML <linux-kernel@vger.kernel.org>,
	"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
	"yamamoto@valinux.co.jp" <yamamoto@valinux.co.jp>,
	ryov@valinux.co.jp
Subject: Re: [PATCH -mm][preview] memcg: a patch series for next [8/9]
Date: Fri, 22 Aug 2008 19:29:43 +0900	[thread overview]
Message-ID: <20080822192943.4009a7b5.nishimura@mxp.nes.nec.co.jp> (raw)
In-Reply-To: <20080819174404.80dd5102.kamezawa.hiroyu@jp.fujitsu.com>

Hi.

I think you are making updated ones, I send comments so far.

On Tue, 19 Aug 2008 17:44:04 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Very experimental...
> 
> mem+swap controller prototype.
> 
> This patch adds CONFIG_CGROUP_MEM_RES_CTLR_SWAP as memory resource
> controller's swap extension.
> 
> When enabling this, memory resource controller will have 2 limits.
> 
>  - memory.limit_in_bytes .... limit for pages
>  - memory.memsw_limit_in_bytes .... limit for pages + swaps.
> 
> Following is (easy) accounting state transion after this patch.
> 
>    pages   swaps    pages_total   memsw_total
>     +1       -           +1           +1        new page allocation.
>     -1      +1           -1           -         swap out.
>     +1      -1            0           -         swap in (*).
>     -       -1           -            -1        swap_free.
> 
What do you mean by "pages_total"?

> At swap-out, swp_entry will be charged against the cgroup of the page.
> At swap-in, the page will be charged when it's mapped.
> (Maybe accounting at read_swap() will be beautiful but we can avoid some of
>  error handling to delay accounting until mem_cgroup_charge().)
> 
> The charge against swap_entry will be uncharged when swap_entry is freed.
> 
> The parameter res.swaps just includes swaps not-on swap cache.
> So, this doesn't show real usage of swp_entry just shows swp_entry on disk.
> 
IMHO, it would be better to "show" real usage of swp_entry.
Otherwise, "sum of swap usage of all groups" != "swap usage of
system shown by meminfo"(but it means adding another counter, hmm...).

Instead of showing the usage of disk_swap, how about showing
the memsw total usage, which is to be limited by user.

> This patch doesn't include codes for control files.
> 
> TODO:
>   - clean up. and add comments.
>   - support vm_swap_full() under cgroup.
Is it needed?

In my swap controller, swap entries are limited per cgroup.
So, to make swap_cgroup_charge() fail less frequently,
vm_swap_full() should be calculated per cgroup so that
vm can free swap entries in advance.

But I think in mem+swap controller the situation is different.

>   - find easier-to-understand protocol....
>   - check force_empty....(maybe buggy)
>   - support page migration.
>   - test!!
> 
And,
- move charge along with task move
- hierarchy support

Of course, more basic features and stabilization should be done first.


I agree with this patch as a whole, but I'm worrying about race
between swapout and swapin about the same entry(I should consider more...).


Thanks,
Daisuke Nishimura.

  reply	other threads:[~2008-08-22 10:49 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-19  8:30 [PATCH -mm][preview] memcg: a patch series for next [0/9] KAMEZAWA Hiroyuki
2008-08-19  8:37 ` [PATCH -mm][preview] memcg: a patch series for next [1/9] KAMEZAWA Hiroyuki
2008-08-19  8:38   ` [PATCH -mm][preview] memcg: a patch series for next [2/9] KAMEZAWA Hiroyuki
2008-08-19  8:39   ` [PATCH -mm][preview] memcg: a patch series for next [3/9] KAMEZAWA Hiroyuki
2008-08-19  8:40   ` [PATCH -mm][preview] memcg: a patch series for next [4/9] KAMEZAWA Hiroyuki
2008-08-19  8:41   ` [PATCH -mm][preview] memcg: a patch series for next [5/9] KAMEZAWA Hiroyuki
2008-08-19  8:42   ` [PATCH -mm][preview] memcg: a patch series for next [6/9] KAMEZAWA Hiroyuki
2008-08-19  8:43   ` [PATCH -mm][preview] memcg: a patch series for next [7/9] KAMEZAWA Hiroyuki
2008-08-19  8:44   ` [PATCH -mm][preview] memcg: a patch series for next [8/9] KAMEZAWA Hiroyuki
2008-08-22 10:29     ` Daisuke Nishimura [this message]
2008-08-22 11:54       ` KAMEZAWA Hiroyuki
2008-08-19  8:44   ` [PATCH -mm][preview] memcg: a patch series for next [9/9] KAMEZAWA Hiroyuki
2008-08-19  9:11 ` [PATCH -mm][preview] memcg: a patch series for next [0/9] Daisuke Nishimura
2008-08-20  1:26   ` KAMEZAWA Hiroyuki
2008-08-20  3:30 ` Balbir Singh
2008-08-20  3:51   ` KAMEZAWA Hiroyuki
2008-08-20  9:53 ` [RFC][PATCH -mm 0/7] memcg: lockless page_cgroup v1 KAMEZAWA Hiroyuki
2008-08-20  9:55   ` [RFC][PATCH -mm 1/7] memcg: page_cgroup_atomic_flags.patch KAMEZAWA Hiroyuki
2008-08-20  9:59   ` [RFC][PATCH -mm 2/7] memcg: delayed_batch_freeing_of_page_cgroup.patch KAMEZAWA Hiroyuki
2008-08-20 10:03   ` [RFC][PATCH -mm 3/7] memcg: freeing page_cgroup by rcu.patch KAMEZAWA Hiroyuki
2008-08-20 10:04   ` [RFC][PATCH -mm 4/7] memcg: lockless page_cgroup KAMEZAWA Hiroyuki
2008-08-20 10:05   ` [RFC][PATCH -mm 5/7] memcg: prefetch mem cgroup per zone KAMEZAWA Hiroyuki
2008-08-20 10:07   ` [RFC][PATCH -mm 6/7] memcg: make-mapping-null-before-calling-uncharge.patch KAMEZAWA Hiroyuki
2008-08-22  4:57     ` Daisuke Nishimura
2008-08-22  5:48       ` KAMEZAWA Hiroyuki
2008-08-20 10:08   ` [RFC][PATCH -mm 7/7] memcg: add page_cgroup.h header file KAMEZAWA Hiroyuki
2008-08-20 10:41   ` [RFC][PATCH -mm 0/7] memcg: lockless page_cgroup v1 KAMEZAWA Hiroyuki
2008-08-20 11:00     ` KAMEZAWA Hiroyuki
2008-08-21  2:17       ` KAMEZAWA Hiroyuki
2008-08-21  3:36         ` Balbir Singh
2008-08-21  3:58           ` KAMEZAWA Hiroyuki
2008-08-21  3:54         ` Daisuke Nishimura
2008-08-21  8:34       ` KAMEZAWA Hiroyuki
2008-08-20 11:33   ` Hirokazu Takahashi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080822192943.4009a7b5.nishimura@mxp.nes.nec.co.jp \
    --to=nishimura@mxp.nes.nec.co.jp \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryov@valinux.co.jp \
    --cc=yamamoto@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®