From: Rik van Riel <riel@conectiva.com.br>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: Kirk McKusick <mckusick@mckusick.com>,
arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu
Subject: Re: on load control / process swapping
Date: Sat, 12 May 2001 11:28:25 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.21.0105121124110.5468-100000@imladris.rielhome.conectiva> (raw)
In-Reply-To: <200105090018.f490IGR87881@earth.backplane.com>
On Tue, 8 May 2001, Matt Dillon wrote:
> :I know that FreeBSD will swap out sleeping processes, but will it
> :ever swap out running processes? The old BSD VM system would do so
> :(we called it hard swapping). It is possible to get a set of running
> :processes that simply do not all fit in memory, and the only way
> :for them to make forward progress is to cycle them through memory.
>
> I looked at the code fairly carefully last night... it doesn't
> swap out running processes and it also does not appear to swap
> out processes blocked in a page-fault (on I/O). Now, of course
> we can't swap a process out right then (it might be holding locks),
> but I think it would be beneficial to be able to mark the process
> as 'requesting a swapout on return to user mode' or something
> like that.
In the (still very rough) swapping code for Linux I simply do
this as "swapout on next pagefault". The idea behind that is:
1) it's easy, at a page fault we know we can suspend the process
2) if we're thrashing, we want every process to make as much
progress as possible before it's suspended (swapped out),
letting the process run until the next page fault means we
will never suspend a process while it's still able to make
progress
3) thrashing should be a rare situation, so you don't want to
complicate fast-path code like "return to userspace"; instead
we make sure to have as little impact on the rest of the
kernel code as possible
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-05-12 14:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-07 21:16 Rik van Riel
2001-05-07 22:50 ` Matt Dillon
2001-05-07 23:35 ` Rik van Riel
2001-05-08 0:56 ` Matt Dillon
2001-05-12 14:23 ` Rik van Riel
2001-05-12 17:21 ` Matt Dillon
2001-05-12 21:17 ` Rik van Riel
2001-05-12 23:58 ` Matt Dillon
2001-05-13 17:22 ` Rik van Riel
2001-05-15 6:38 ` Terry Lambert
2001-05-15 13:39 ` Cy Schubert - ITSD Open Systems Group
2001-05-15 15:31 ` Rik van Riel
2001-05-15 17:24 ` Matt Dillon
2001-05-15 23:55 ` Roger Larsson
2001-05-16 0:16 ` Matt Dillon
2001-05-16 4:22 ` Kernel Debugger Amarnath Jolad
2001-05-16 7:58 ` Kris Kennaway
2001-05-16 11:42 ` Martin Frey
2001-05-16 12:04 ` R.Oehler
2001-05-16 8:23 ` on load control / process swapping Terry Lambert
2001-05-16 17:26 ` Matt Dillon
2001-05-08 20:52 ` Kirk McKusick
2001-05-09 0:18 ` Matt Dillon
2001-05-09 2:07 ` Peter Jeremy
2001-05-09 19:41 ` Matt Dillon
2001-05-12 14:28 ` Rik van Riel [this message]
2001-05-08 12:25 ` Scott F. Kaplan
2001-05-16 15:17 Charles Randall
2001-05-16 17:14 Matt Dillon
2001-05-16 17:41 ` Rik van Riel
2001-05-16 17:54 ` Matt Dillon
2001-05-18 5:58 ` Terry Lambert
2001-05-18 6:20 ` Matt Dillon
2001-05-18 10:00 ` Andrew Reilly
2001-05-18 13:49 ` Jonathan Morton
2001-05-19 2:18 ` Rik van Riel
2001-05-19 2:56 ` Jonathan Morton
2001-05-16 17:57 ` Alfred Perlstein
2001-05-16 18:01 ` Matt Dillon
2001-05-16 18:10 ` Alfred Perlstein
[not found] <OF5A705983.9566DA96-ON86256A50.00630512@hou.us.ray.com>
2001-05-18 20:13 ` Jonathan Morton
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.21.0105121124110.5468-100000@imladris.rielhome.conectiva \
--to=riel@conectiva.com.br \
--cc=arch@FreeBSD.ORG \
--cc=dillon@earth.backplane.com \
--cc=linux-mm@kvack.org \
--cc=mckusick@mckusick.com \
--cc=sfkaplan@cs.amherst.edu \
/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