From: Nix <nix@esperi.org.uk>
To: "Al Boldi" <a1426z@gawab.com>
Cc: "'Marcelo Tosatti'" <marcelo.tosatti@cyclades.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: Kswapd flaw
Date: Tue, 28 Jun 2005 15:37:26 +0100 [thread overview]
Message-ID: <871x6m5yzd.fsf@amaterasu.srvr.nix> (raw)
In-Reply-To: <200506281352.QAA25851@raad.intranet> (Al Boldi's message of "Tue, 28 Jun 2005 16:52:00 +0300")
On Tue, 28 Jun 2005, Al Boldi wrote:
> Hi Nix, how are you?
> You wrote: {
> On 28 Jun 2005, Al Boldi yowled:
>> Please do flush anytime, and do it in sync during OOMs; but don't
>> evict procs especially not RUNNING procs, that is overkill.
>
> Would you really like a system where once something was faulted in, it could
> never leave? You'd run out of memory *awfully* fast.
> }
>
> You should only fault if you have a place to fault to, as into a swap.
> Without swap faulting is overkill.
That's `swapping', i.e. writing out dirty data pages (and text pages
dirtied by e.g. relocation) which otherwise have nowhere to go.
Pages mapped from files with read-only mappings and non-dirty pages of
read-write mappings get discarded when memory is tight; pages mapped
with read-write non-private maps and which have been modified get
written back to their file and discarded in the same situation.
(Private modified read-write mappings of data files have to stay in
memory: the only place they could go is swap, and there is none.)
> Is it possible to change kswapd's default behaviour to not fault if
> there is no swap?
I don't think so, except on a process-by-process basis via mlockall().
(/proc/sys/vm/swappiness lets you say that swapping is more or less
desirable, but under enough memory pressure paging *will* happen
regardless of the value of that variable.)
You can kludge it to some extent by putting your binaries in a tmpfs and
running from there: then you'll be paging from memory to memory ;)
But I'm mystified as to why you might want to suppress paging. The only
effect of suppressing it is to reduce the amount of memory you can
allocate before you run completely out and start killing things. Surely
slow execution is generally preferable to *no* execution?
(Or is it that you're trying to suppress *disk activity*, perhaps to
keep power consumption down? If so, running from tmpfs seems the best
option.)
--
`I lost interest in "blade servers" when I found they didn't throw knives
at people who weren't supposed to be in your machine room.'
--- Anthony de Boer
next prev parent reply other threads:[~2005-06-28 14:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-27 20:04 Kswapd flaw Al Boldi
2005-06-27 15:58 ` Marcelo Tosatti
2005-06-28 6:37 ` Al Boldi
2005-06-28 8:18 ` Michal Schmidt
2005-06-28 9:08 ` Al Boldi
2005-06-28 9:54 ` Michal Schmidt
2005-06-28 10:50 ` Nix
2005-06-28 11:47 ` Al Boldi
2005-06-28 12:50 ` Nix
2005-06-28 13:52 ` Al Boldi
2005-06-28 14:37 ` Nix [this message]
2005-06-28 15:35 ` Al Boldi
2005-06-28 16:25 ` Nix
2005-06-28 18:15 ` Helge Hafting
2005-06-28 14:55 ` Paulo Marques
2005-06-28 9:58 ` Marcelo Tosatti
2005-06-28 16:43 ` Al Boldi
[not found] <4knRo-4Li-9@gated-at.bofh.it>
[not found] ` <4koWT-5Iy-21@gated-at.bofh.it>
2005-06-28 14:28 ` Robert Hancock
[not found] <20050628143932.GA14545@logos.cnet>
2005-06-29 4:53 ` Al Boldi
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=871x6m5yzd.fsf@amaterasu.srvr.nix \
--to=nix@esperi.org.uk \
--cc=a1426z@gawab.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
/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