linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Morton <chromi@cyberspace.org>
To: Mark_H_Johnson@Raytheon.com
Cc: linux-mm@kvack.org
Subject: Re: on load control / process swapping
Date: Fri, 18 May 2001 21:13:27 +0100	[thread overview]
Message-ID: <l03130304b72b2f631e14@[192.168.239.105]> (raw)
In-Reply-To: <OF5A705983.9566DA96-ON86256A50.00630512@hou.us.ray.com>

>I'm not sure you have these items measured in the kernel at this point, but
>VAX/VMS used the page replacement rate to control the working set size
>(Linux term - resident set size) within three limits...
> - minimum working set size
> - maximum guaranteed working set size (under memory pressure)
> - maximum extended working set size (no memory pressure)
>The three sizes above were enforced on a per user basis. I could see using
>the existing Linux RSS limit for the maximum guarantee (or extended) and
>then ratios for the other items.

Seems reasonable, but remember RSS != working set.  Under "normal"
conditions we want all processes to have all the memory they want, then
when memory pressure encroaches we want to keep as many processes as
possible with their working set swapped in (but no more).

>There were several parameters - some on a per system basis and others on a
>per user basis [I can't recall which were which] to control this
>including...
> - amount to increase the working set size (say 5-10% of the maximum)
> - amount to decrease the working set size (usually about 1/2 the increase
>size value)
> - pages per second replaced in the working set to trigger a possible
>increase (say 10)
> - pages per second replaced in the working set to trigger a possible
>decrease (say 2 or 1)
>A new job would start at its minimum size and grow quickly to either the
>maximum limit or its natural working set size. If at the limit, it would
>thrash but not necessarily affect the other jobs on the system. I am not
>sure how the numbers I listed would apply with a fast system with huge
>memories - the values I listed were what I recall on what would be a small
>system today (4M to 64M).

Hmm, it looks to me like the algorithm above relies on a continuous rate of
paging.  This is a bad thing on a modern system where the swap device is so
much slower than main memory.  However, the idea is an interesting one and
could possibly be adapted...

The key thing is that maximum performance for a given process (particularly
a small one) is when *no* paging is occurring in relation to it.  Under
memory pressure, this is quite hard to achieve unless the working set is
already known.  Thus the VMS model (if I understood it correctly) doesn't
work so well for modern systems running Linux.

What i was really asking, to make the question clearer is "how does
page->age work?  And if it's not suitable for WS calculation in the ways
that I suspect, what else could be used - that is *already* instrumented?".

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----


--
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/

       reply	other threads:[~2001-05-18 20:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF5A705983.9566DA96-ON86256A50.00630512@hou.us.ray.com>
2001-05-18 20:13 ` Jonathan Morton [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2001-05-16 15:17 Charles Randall
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  8:23                 ` 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
2001-05-08 12:25 ` Scott F. Kaplan

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='l03130304b72b2f631e14@[192.168.239.105]' \
    --to=chromi@cyberspace.org \
    --cc=Mark_H_Johnson@Raytheon.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