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 02:18:26 +0530 [thread overview]
Message-ID: <46EEE81A.1010404@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0709172038090.25512@blonde.wat.veritas.com>
Hugh Dickins wrote:
> On Tue, 18 Sep 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>> 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.
>> 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
>
> Neither of those makes sense to me, but I may be misunderstanding.
>
> What would make sense is (what I meant when I said swap counted
> along with RSS) not to count pages out and back in as they are
> go out to swap and back in, just keep count of instantiated pages
>
I am not sure how you define instantiated pages. I suspect that
you mean RSS + pages swapped out (swap_pte)?
> I say "make sense" meaning that the numbers could be properly
> accounted; but it may well be unpalatable to treat fast RAM as
> equal to slow swap.
>
>> 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?
>
> That's not so bad. What's bad is that anyone else with the
> CAP_SYS_ADMIN to swapoff is liable to be prevented by containers
> going over their limits.
>
If a swapoff is going to push a container over it's limit, then
we break the container and the isolation it provides. Upon swapoff
failure, may be we could get the container to print a nice
little warning so that anyone else with CAP_SYS_ADMIN can fix the
container limit and retry swapoff.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
WARNING: multiple messages have this Message-ID (diff)
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 02:18:26 +0530 [thread overview]
Message-ID: <46EEE81A.1010404@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0709172038090.25512@blonde.wat.veritas.com>
Hugh Dickins wrote:
> On Tue, 18 Sep 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>> 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.
>> 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
>
> Neither of those makes sense to me, but I may be misunderstanding.
>
> What would make sense is (what I meant when I said swap counted
> along with RSS) not to count pages out and back in as they are
> go out to swap and back in, just keep count of instantiated pages
>
I am not sure how you define instantiated pages. I suspect that
you mean RSS + pages swapped out (swap_pte)?
> I say "make sense" meaning that the numbers could be properly
> accounted; but it may well be unpalatable to treat fast RAM as
> equal to slow swap.
>
>> 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?
>
> That's not so bad. What's bad is that anyone else with the
> CAP_SYS_ADMIN to swapoff is liable to be prevented by containers
> going over their limits.
>
If a swapoff is going to push a container over it's limit, then
we break the container and the isolation it provides. Upon swapoff
failure, may be we could get the container to print a nice
little warning so that anyone else with CAP_SYS_ADMIN can fix the
container limit and retry 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 20:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 18:57 [PATCH mm] fix swapoff breakage; however Hugh Dickins
2007-09-17 18:57 ` Hugh Dickins
2007-09-17 19:12 ` Balbir Singh
2007-09-17 19:12 ` Balbir Singh
2007-09-17 19:51 ` Hugh Dickins
2007-09-17 19:51 ` Hugh Dickins
2007-09-17 20:48 ` Balbir Singh [this message]
2007-09-17 20:48 ` Balbir Singh
2007-09-17 22:36 ` Hugh Dickins
2007-09-17 22:36 ` Hugh Dickins
2007-09-18 4:23 ` Balbir Singh
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=46EEE81A.1010404@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 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.