linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@in.ibm.com>
To: Pavel Emelianov <xemul@openvz.org>
Cc: vatsa@in.ibm.com, dev@openvz.org, sekharan@us.ibm.com,
	ckrm-tech@lists.sourceforge.net, haveblue@us.ibm.com,
	linux-kernel@vger.kernel.org, pj@sgi.com, matthltc@us.ibm.com,
	dipankar@in.ibm.com, rohitseth@google.com, menage@google.com,
	linux-mm@kvack.org
Subject: Re: [ckrm-tech] RFC: Memory Controller
Date: Tue, 31 Oct 2006 18:09:14 +0530	[thread overview]
Message-ID: <454743F2.6010305@in.ibm.com> (raw)
In-Reply-To: <4547305A.9070903@openvz.org>

Pavel Emelianov wrote:
>> That's like disabling memory over-commit in the regular kernel.
> 
> Nope. We limit only unreclaimable mappings. Allowing user
> to break limits breaks the sense of limit.
> 
> Or you do not agree that allowing unlimited unreclaimable
> mappings doesn't alow you the way to cut groups gracefully?
> 


A quick code review showed that most of the accounting is the
same.

I see that most of the mmap accounting code, it seems to do
the equivalent of security_vm_enough_memory() when VM_ACCOUNT
is set. May be we could merge the accounting code to handle
even containers.

I looked at

do_mmap_pgoff
acct_stack_growth
__do_brk (
do_mremap


> [snip]
> 
>> Please see the patching of Rohit's memory controller for user
>> level patching. It seems much simpler.
> 
> Could you send me an URL where to get the patch from, please.
> Or the patch itself directly to me. Thank you.

Please see http://lkml.org/lkml/2006/9/19/283

> 
> [snip]
> 
>> I would prefer a different set
>>
>> 1 & 2, for now we could use any interface and then start developing the
>> controller. As we develop the new controller, we are likely to find the
>> need to add/enhance the interface, so freezing in on 1 & 2 might not be
>> a good idea.
> 
> Paul Menage won't agree. He believes that interface must come first.
> I also remind you that the latest beancounter patch provides all the
> stuff we're discussing. It may move tasks, limit all three resources
> discussed, reclaim memory and so on. And configfs interface could be
> attached easily.
> 

I think the interface should depend on the controllers and not
the other way around. I fear that the infrastructure discussion might
hold us back and no fruitful work will happen on the controllers.
Once we add and agree on the controller, we can then look at the
interface requirements (like persistence if kernel memory is being
tracked, etc). What do you think?

>> I would put 4, 5 and 6 ahead of 3, based on the changes I see in Rohit's
>> memory controller.
>>
>> Then take up the rest.
> 
> I'll review Rohit's patches and comment.

ok



-- 
	Thanks,
	Balbir Singh,
	Linux Technology Center,
	IBM Software Labs

--
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>

  reply	other threads:[~2006-10-31 12:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20061030103356.GA16833@in.ibm.com>
     [not found] ` <4545D51A.1060808@in.ibm.com>
     [not found]   ` <4546212B.4010603@openvz.org>
     [not found]     ` <454638D2.7050306@in.ibm.com>
2006-10-30 18:07       ` Balbir Singh
2006-10-31  8:57         ` Pavel Emelianov
2006-10-31  9:19           ` Balbir Singh
2006-10-31  9:25             ` Pavel Emelianov
2006-10-31 10:10               ` Balbir Singh
2006-10-31 10:19                 ` Pavel Emelianov
2006-10-31  9:42             ` Andrew Morton
2006-10-31 10:36               ` Balbir Singh
     [not found]       ` <45470DF4.70405@openvz.org>
2006-10-31 10:54         ` Balbir Singh
2006-10-31 11:15           ` Pavel Emelianov
2006-10-31 12:39             ` Balbir Singh [this message]
2006-10-31 14:19               ` Pavel Emelianov
2006-10-31 16:54             ` Paul Menage
2006-11-01  6:00             ` David Rientjes
2006-11-01  8:05               ` Pavel Emelianov
2006-11-01  8:35                 ` David Rientjes

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=454743F2.6010305@in.ibm.com \
    --to=balbir@in.ibm.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=dev@openvz.org \
    --cc=dipankar@in.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthltc@us.ibm.com \
    --cc=menage@google.com \
    --cc=pj@sgi.com \
    --cc=rohitseth@google.com \
    --cc=sekharan@us.ibm.com \
    --cc=vatsa@in.ibm.com \
    --cc=xemul@openvz.org \
    /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