From: Dave McCracken <dmc@austin.ibm.com>
To: linux-mm@kvack.org
Subject: Re: suspend processes at load (was Re: a simple OOM ...)
Date: Thu, 19 Apr 2001 13:25:45 -0500 [thread overview]
Message-ID: <7370000.987704745@baldur> (raw)
In-Reply-To: <l03130303b704a08b5dde@[192.168.239.105]>
--On Thursday, April 19, 2001 15:03:28 +0100 Jonathan Morton
<chromi@cyberspace.org> wrote:
> My proposal is to introduce a better approximation to LRU in the VM,
> solely for the purpose of determining the working set. No alterations to
> the page replacement policy are needed per se, except to honour the
> "allowed working set" for each process as calculated below.
>
> (...)
>
> - Calculate the total physical quota for all processes as the sum of all
> working sets (plus unswappable memory such as kernel, mlock(), plus a
> small chunk to handle buffers, cache, etc.)
> - If this total is within the physical memory of the system, the physical
> quota for each process is the same as it's working set. (fast common
> case) - Otherwise, locate the process with the largest quota and remove
> it from the total quota. Add in "a few" pages to ensure this process
> always has *some* memory to work in. Repeat this step until the physical
> quota is within physical memory or no processes remain.
> - Any remaining processes after this step get their full working set as
> physical quota. Processes removed from the list get equal share of
> (remaining physical memory, minus the chunk for buffers, cache and so on).
It appears to me that the end result of all this is about the same as
suspending a few selected processes. Under your algorithm the processes
that have no guaranteed working set make no real progress and the others
get to run. It seems like a significant amount of additional overhead to
end up with the same result. Additionally, those processes will be
generating large numbers of page faults as they fight over the scrap of
memory they have. Using the suspension algorithm they'll be removed
entirely from running, this freeing up resources for the remaining
processes.
Dave McCracken
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
dmc@austin.ibm.com T/L 678-3059
--
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-04-19 18:27 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-19 14:03 Jonathan Morton
2001-04-19 18:25 ` Dave McCracken [this message]
2001-04-19 18:32 ` James A. Sutherland
2001-04-19 20:23 ` Jonathan Morton
2001-04-20 12:14 ` Szabolcs Szakacsits
2001-04-20 12:02 ` Jonathan Morton
2001-04-20 14:48 ` Dave McCracken
2001-04-21 5:49 ` James A. Sutherland
2001-04-21 19:16 ` Joseph A. Knapka
2001-04-21 19:41 ` Jonathan Morton
2001-04-22 10:08 ` James A. Sutherland
2001-04-22 16:53 ` Jonathan Morton
2001-04-22 17:06 ` James A. Sutherland
2001-04-22 18:18 ` Jonathan Morton
2001-04-22 18:57 ` Rik van Riel
2001-04-22 19:41 ` James A. Sutherland
2001-04-22 20:33 ` Jean Francois Martinez
2001-04-22 20:21 ` Jonathan Morton
2001-04-22 20:36 ` Jonathan Morton
2001-04-22 19:01 ` James A. Sutherland
2001-04-22 19:11 ` Rik van Riel
2001-04-22 20:36 ` James A. Sutherland
2001-04-22 19:30 ` Jonathan Morton
2001-04-22 20:35 ` James A. Sutherland
2001-04-22 20:41 ` Rik van Riel
2001-04-22 20:58 ` James A. Sutherland
2001-04-22 21:26 ` Rik van Riel
2001-04-22 22:26 ` Jonathan Morton
2001-04-23 5:55 ` James A. Sutherland
2001-04-23 5:59 ` Rik van Riel
2001-04-21 20:29 ` Rik van Riel
2001-04-22 10:08 ` James A. Sutherland
-- strict thread matches above, loose matches on Subject: below --
2001-04-13 16:20 [PATCH] a simple OOM killer to save me from Netscape Rik van Riel
2001-04-16 12:17 ` suspend processes at load (was Re: a simple OOM ...) Szabolcs Szakacsits
2001-04-17 19:48 ` Rik van Riel
2001-04-18 21:32 ` Szabolcs Szakacsits
2001-04-18 20:38 ` James A. Sutherland
2001-04-18 23:25 ` Szabolcs Szakacsits
2001-04-18 22:29 ` Rik van Riel
2001-04-19 10:14 ` Stephen C. Tweedie
2001-04-19 13:23 ` Szabolcs Szakacsits
2001-04-19 2:11 ` Rik van Riel
2001-04-19 7:08 ` James A. Sutherland
2001-04-19 13:37 ` Szabolcs Szakacsits
2001-04-19 12:26 ` Christoph Rohland
2001-04-19 12:30 ` James A. Sutherland
2001-04-19 9:15 ` James A. Sutherland
2001-04-19 18:34 ` Dave McCracken
2001-04-19 18:47 ` James A. Sutherland
2001-04-19 18:53 ` Dave McCracken
2001-04-19 19:10 ` James A. Sutherland
2001-04-20 14:58 ` Rik van Riel
2001-04-21 6:10 ` James A. Sutherland
2001-04-19 19:13 ` Rik van Riel
2001-04-19 19:47 ` Gerrit Huizenga
2001-04-20 12:44 ` Szabolcs Szakacsits
2001-04-19 20:06 ` James A. Sutherland
2001-04-20 12:29 ` Szabolcs Szakacsits
2001-04-20 11:50 ` Jonathan Morton
2001-04-20 13:32 ` Szabolcs Szakacsits
2001-04-20 14:30 ` Rik van Riel
2001-04-22 10:21 ` James A. Sutherland
2001-04-20 12:25 ` Szabolcs Szakacsits
2001-04-21 6:08 ` James A. Sutherland
2001-04-20 12:18 ` Szabolcs Szakacsits
2001-04-22 10:19 ` James A. Sutherland
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=7370000.987704745@baldur \
--to=dmc@austin.ibm.com \
--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