From: Hugh Dickins <hugh@veritas.com>
To: Balbir Singh <balbir@linux.vnet.ibm.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: Mon, 17 Sep 2007 23:36:38 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0709172312390.19506@blonde.wat.veritas.com> (raw)
In-Reply-To: <46EEE81A.1010404@linux.vnet.ibm.com>
On Tue, 18 Sep 2007, Balbir Singh wrote:
> Hugh Dickins wrote:
> >
> > 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)?
That's it. (Whereas file pages counted out when paged out,
then counted back in when paged back in.)
> If a swapoff is going to push a container over it's limit, then
> we break the container and the isolation it provides.
Is it just my traditional bias, that makes me prefer you break
your container than my swapoff? I'm not sure.
> 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.
And then they hit the next one... rather like trying to work out
the dependencies of packages for oneself: a very tedious process.
If the swapoff succeeds, that does mean there was actually room
in memory (+ other swap) for everyone, even if some have gone over
their nominal limits. (But if the swapoff runs out of memory in
the middle, yes, it might well have assigned the memory unfairly.)
The appropriate answer may depend on what you do when a container
tries to fault in one more page than its limit. Apparently just
fail it (no attempt to page out another page from that container).
So, if the whole system is under memory pressure, kswapd will
be keeping the RSS of all tasks low, and they won't reach their
limits; whereas if the system is not under memory pressure,
tasks will easily approach their limits and so fail.
Please tell me my understanding is wrong!
Hugh
--
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 22:36 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
2007-09-17 19:51 ` Hugh Dickins
2007-09-17 20:48 ` Balbir Singh
2007-09-17 22:36 ` Hugh Dickins [this message]
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=Pine.LNX.4.64.0709172312390.19506@blonde.wat.veritas.com \
--to=hugh@veritas.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.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