From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH mm] fix swapoff breakage; however...
Date: Tue, 18 Sep 2007 00:42:39 +0530 [thread overview]
Message-ID: <46EED1A7.5080606@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0709171947130.15413@blonde.wat.veritas.com>
Hugh Dickins wrote:
> rc4-mm1's memory-controller-memory-accounting-v7.patch broke swapoff:
> it extended unuse_pte_range's boolean "found" return code to allow an
> error return too; but ended up returning found (1) as an error.
> Replace that by success (0) before it gets to the upper level.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
> More fundamentally, it looks like any container brought over its limit in
> unuse_pte will abort swapoff: that doesn't doesn't seem "contained" to me.
> Maybe unuse_pte should just let containers go over their limits without
> error? Or swap should be counted along with RSS? Needs reconsideration.
>
> mm/swapfile.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.23-rc4-mm1/mm/swapfile.c 2007-09-07 13:09:42.000000000 +0100
> +++ linux/mm/swapfile.c 2007-09-17 15:14:47.000000000 +0100
> @@ -642,7 +642,7 @@ static int unuse_mm(struct mm_struct *mm
> break;
> }
> up_read(&mm->mmap_sem);
> - return ret;
> + return (ret < 0)? ret: 0;
Thanks, for the catching this. There are three possible solutions
1. Account each RSS page with a probable swap cache page, double
the RSS accounting to ensure that swapoff will not fail.
2. Account for the RSS page just once, do not account swap cache
pages
3. Follow your suggestion and let containers go over their limits
without error
With the current approach, a container over it's limit will not
be able to call swapoff successfully, is that bad?
We plan to implement per container/per cpuset swap in the future.
Given that, isn't this expected functionality. You are over it's
limit cannot really swapoff a swap device. If we allow pages to
be unused, we could end up with a container that could exceed
it's limit by a significant amount by calling swapoff.
> }
>
> /*
--
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-09-17 19:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 18:57 Hugh Dickins
2007-09-17 19:12 ` Balbir Singh [this message]
2007-09-17 19:51 ` Hugh Dickins
2007-09-17 20:48 ` Balbir Singh
2007-09-17 22:36 ` Hugh Dickins
2007-09-18 4:23 ` 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=46EED1A7.5080606@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--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