linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
To: Rik van Riel <H.H.vanRiel@fys.ruu.nl>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
	"Stephen C. Tweedie" <sct@dcs.ed.ac.uk>,
	torvalds@transmeta.com, blah@kvack.org, nahshon@actcom.co.il,
	alan@lxorguk.ukuu.org.uk, paubert@iram.es,
	linux-kernel@vger.rutgers.edu, mingo@chiara.csoma.elte.hu,
	linux-mm@kvack.org
Subject: Re: Fairness in love and swapping
Date: Thu, 26 Feb 1998 22:41:26 GMT	[thread overview]
Message-ID: <199802262241.WAA03911@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.91.980226152230.878A-100000@mirkwood.dummy.home>

Hi,

On Thu, 26 Feb 1998 15:30:25 +0100 (MET), Rik van Riel
<H.H.vanRiel@fys.ruu.nl> said:

> Now, how do we select which processes to suspend temporarily
> and which to wake up again...
> Suspending X wouldn't be to good, since then a lot of other
> procesess would block on it... But this gives us a good clue
> as to what to do.

> We could:
> - force-swap out processes which have slept for some time
> - suspend & force-swap out the largest process
> - wake it up again when there are two proceses waiting on
>   it (to prevent X from being swapped out)

Define the number of processes waiting on a given process?

Another way of making the distinction between batch and interactive
processes might be to observe that interactive processes spend some of
their time in "S" (interruptible sleep) state, whereas we expect
compute-bound jobs to be in "R" or "D" state most of the time.
However, that breaks down too when you consider batch jobs involving
pipelines, such as gcc -pipe.

> Doing this together with a dynamic RSS-limit strategy and
> page cache page aging might give us quite an improvement
> in VM performance.

Yes, and doing streamed writeahead and clustered swapin will up the
throughput to/from swap quite significantly too.

Cheers,
 Stephen.

  reply	other threads:[~1998-02-26 22:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-02-25 20:32 Stephen C. Tweedie
1998-02-25 21:02 ` Linus Torvalds
1998-02-25 21:44   ` Rik van Riel
1998-02-25 21:39 ` Dr. Werner Fink
1998-02-25 22:27   ` Rik van Riel
1998-02-26 11:03     ` Dr. Werner Fink
1998-02-26 11:34       ` Rik van Riel
1998-02-26 18:57         ` Dr. Werner Fink
1998-02-26 19:32           ` Rik van Riel
1998-02-26 22:44         ` Stephen C. Tweedie
1998-02-26 23:34           ` Rik van Riel
1998-02-27 19:41             ` Stephen C. Tweedie
1998-03-02 16:19               ` Rik van Riel
1998-03-02 22:35                 ` Stephen C. Tweedie
1998-03-02 23:14                   ` Rik van Riel
1998-03-03 22:59                     ` Stephen C. Tweedie
1998-02-26  8:05 ` Rogier Wolff
1998-02-26 13:00   ` Dr. Werner Fink
1998-02-26 22:36     ` Stephen C. Tweedie
1998-02-26 23:20       ` Dr. Werner Fink
1998-02-26 14:30   ` Rik van Riel
1998-02-26 22:41     ` Stephen C. Tweedie [this message]
1998-02-26 23:21       ` Rik van Riel
1998-02-26 22:33   ` Stephen C. Tweedie
1998-02-26 22:49     ` Rik van Riel
1998-02-27  2:56     ` Michael O'Reilly
     [not found] <199802270729.IAA00680@cave.BitWizard.nl>
1998-02-27 11:26 ` Rik van Riel

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=199802262241.WAA03911@dax.dcs.ed.ac.uk \
    --to=sct@dcs.ed.ac.uk \
    --cc=H.H.vanRiel@fys.ruu.nl \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=blah@kvack.org \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=mingo@chiara.csoma.elte.hu \
    --cc=nahshon@actcom.co.il \
    --cc=paubert@iram.es \
    --cc=torvalds@transmeta.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