All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"hugh@veritas.com" <hugh@veritas.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"menage@google.com" <menage@google.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: memo: mem+swap controller
Date: Fri, 01 Aug 2008 08:58:07 +0530	[thread overview]
Message-ID: <489282C7.2020500@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080731152533.dea7713a.nishimura@mxp.nes.nec.co.jp>

Daisuke Nishimura wrote:
> Hi, Kamezawa-san.
> 
> On Thu, 31 Jul 2008 10:15:33 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>> Hi, mem+swap controller is suggested by Hugh Dickins and I think it's a great
>> idea. Its concept is having 2 limits. (please point out if I misunderstand.)
>>
>>  - memory.limit_in_bytes       .... limit memory usage.
>>  - memory.total_limit_in_bytes .... limit memory+swap usage.
>>
> When I've considered more, I wonder how we can accomplish
> "do not use swap in this group".
> 

It's easy use the memrlimit controller and set virtual address limit <=
memory.limit_in_bytes. I use that to make sure I never swap out.

> Setting "limit_in_bytes == total_limit_in_bytes" doesn't meet it, I think.
> "limit_in_bytes = total_limit_in_bytes = 1G" cannot
> avoid "memory.usage = 700M swap.usage = 300M" under memory pressure
> outside of the group(and I think this behavior is the diffrence
> of "memory controller + swap controller" and "mem+swap controller").
> 
> I think total_limit_in_bytes and swappiness(or some flag to indicate
> "do not swap out"?) for each group would make more sense.

I do intend to add the swappiness feature soon for control groups.

> 
>> By this, we can avoid excessive use of swap under a cgroup without any bad effect
>> to global LRU. (in page selection algorithm...overhead will be added, of course)
>>
> Sorry, I cannot understand this part.
> 
>> Following is state transition and counter handling design memo.
>> This uses "3" counters to handle above conrrectly. If you have other logic,
>> please teach me. (and blame me if my diagram is broken.)
>>
> I don't think counting "disk swap" is good idea(global linux
> dosen't count it).
> Instead, I prefer counting "total swap"(that is swap entry).
> 
>> A point is how to handle swap-cache, I think.
>> (Maybe we need a _big_ change in memcg.)
>>
> I think swap cache should be counted as both memory and swap,
> as global linux does.
> 
[snip]
-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2008-08-01  3:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-31  1:15 memo: mem+swap controller KAMEZAWA Hiroyuki
2008-07-31  6:18 ` KOSAKI Motohiro
2008-07-31  6:25 ` Daisuke Nishimura
2008-07-31  6:51   ` KAMEZAWA Hiroyuki
2008-07-31 13:03     ` Daisuke Nishimura
2008-07-31 16:31       ` kamezawa.hiroyu
2008-08-01  3:05         ` Daisuke Nishimura
2008-08-01  3:28   ` Balbir Singh [this message]
2008-08-01  4:02     ` Daisuke Nishimura
2008-08-01  4:13       ` Balbir Singh
2008-08-01  4:57         ` Daisuke Nishimura
2008-08-01  5:07         ` memcg swappiness (Re: memo: mem+swap controller) YAMAMOTO Takashi
2008-08-01  5:25           ` Balbir Singh
2008-08-01  6:37             ` YAMAMOTO Takashi
2008-08-01  6:46               ` Balbir Singh
2008-09-09  9:17                 ` YAMAMOTO Takashi
2008-09-09 14:07                   ` Balbir Singh
2008-08-01  3:20 ` memo: mem+swap controller Balbir Singh
2008-08-01  3:45   ` KAMEZAWA Hiroyuki

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=489282C7.2020500@linux.vnet.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=menage@google.com \
    --cc=nishimura@mxp.nes.nec.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.