From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Linux Containers <containers@lists.osdl.org>,
Linux MM Mailing List <linux-mm@kvack.org>
Subject: Re: [RFC] [-mm PATCH] Memory controller fix swap charging context in unuse_pte()
Date: Tue, 30 Oct 2007 03:31:38 +0530 [thread overview]
Message-ID: <47265842.5040506@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0710292101510.23980@blonde.wat.veritas.com>
Hugh Dickins wrote:
> On Mon, 29 Oct 2007, Balbir Singh wrote:
>> On Mon, Oct 29, 2007 at 01:57:40AM +0530, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>
>> [snip]
>>
>>> Without your mem_cgroup mods in mm/swap_state.c, unuse_pte makes
>>> the right assignments (I believe). But I find that swapout (using
>>> 600M in a 512M machine) from a 200M cgroup quickly OOMs, whereas
>>> it behaves correctly with your mm/swap_state.c.
>>>
>> On my UML setup, I booted the UML instance with 512M of memory and
>> used the swapout program that you shared. I tried two things
>>
>>
>> 1. Ran swapout without any changes. The program ran well without
>> any OOM condition occuring, lot of reclaim occured.
>> 2. Ran swapout with the changes to mm/swap_state.c removed (diff below)
>> and I still did not see any OOM. The reclaim count was much lesser
>> since swap cache did not get accounted back to the cgroup from
>> which pages were being evicted.
>>
>> I am not sure why I don't see the OOM that you see, still trying. May be
>> I missing something obvious at this late hour in the night :-)
>
> I reconfirm that I do see those OOMs. I'll have to try harder to
> analyze how they come about: I sure don't expect you to debug a
> problem you cannot reproduce. But what happens if you try it
> native rather than using UML?
>
> Hugh
On a real box - a powerpc machine that I have access to
1. I don't see the OOM with the mods removed (I have swap
space at-least twice of RAM - with mem=512M, I have at-least
1G of swap).
2. Running under the container is much much faster than running
swapout in the root container. The machine is almost unusable
if swapout is run under the root container
At this momemnt, I suspect one of two things
1. Our mods to swap_state.c are different
2. Our configuration is different, main-memory to swap-size ratio
--
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>
next prev parent reply other threads:[~2007-10-29 22:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-05 4:14 [RFC] [-mm PATCH] Memory controller fix swap charging context in unuse_pte() Balbir Singh
2007-10-07 16:57 ` Hugh Dickins
2007-10-07 17:48 ` Balbir Singh
2007-10-15 17:27 ` Balbir Singh
2007-10-22 18:51 ` Hugh Dickins
2007-10-24 12:14 ` Balbir Singh
2007-10-25 19:33 ` Hugh Dickins
2007-10-26 6:14 ` Balbir Singh
[not found] ` <4724F0BC.1020209@linux.vnet.ibm.com>
2007-10-28 20:32 ` Balbir Singh
2007-10-29 21:07 ` Hugh Dickins
2007-10-29 22:01 ` Balbir Singh [this message]
2007-10-30 16:57 ` Hugh Dickins
2007-10-30 18:28 ` Balbir Singh
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=47265842.5040506@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=containers@lists.osdl.org \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).