linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. Werner Fink" <werner@suse.de>
To: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Kernel Mailing List <linux-kernel@vger.rutgers.edu>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: Linux-2.1.129..
Date: Fri, 20 Nov 1998 13:09:48 +0100	[thread overview]
Message-ID: <19981120130948.20965@boole.suse.de> (raw)
In-Reply-To: <Pine.LNX.3.96.981119225103.18633A-100000@mirkwood.dummy.home>; from Rik van Riel on Thu, Nov 19, 1998 at 10:58:30PM +0100

On Thu, Nov 19, 1998 at 10:58:30PM +0100, Rik van Riel wrote:
> On Thu, 19 Nov 1998, Dr. Werner Fink wrote:
> 
> > Yes on a 512MB system it's a great win ... on a 64 system I see
> > something like a ``swapping weasel'' under high load.
> > 
> > It seems that page ageing or something *similar* would be nice
> > for a factor 512/64 >= 2  ... under high load and not enough
> > memory it's maybe better if we could get the processes in turn
> > into work instead of useless swapping (this was a side effect
> > of page ageing due to the implicit slow down).
> 
> It was certainly a huge win when page aging was implemented,
> but we mainly felt that because there used to be an obscure
> bug in vmscan.c, causing the kernel to always start scanning
> at the start of the process' address space.
> 
> Now that bug is fixed, it might just be better to switch
> to a multi-queue system. A full implementation of that
> will have to wait until 2.3, but we can easily do an
> el-cheapo simulation of it by simply not freeing swap
> cached pages on the first pass of shrink_mmap().

Hmmm ... we need something real for 2.2 ... so,
let's analyse the problem

     If the average time slice of the processes is eaten up by
     swapping page back *and* if these pages are spapped out
     during to the next time slice the system becomes unusable
     (freeing swap cached pages on the first pass of shrink_mmap()
      does force this behaviour at high stress).

Therefore we need something like a page ageing which does not
mean that the old scheme is required.

     Pages which are swapped in need a higher life time in
     physical memory.  If a page can be shared this life
     time could be a bigger one.
     If a process counts such pages up to a limit his pages
     should not get a higher life for the next few cycles.

This simple scheme should be implementable in a easy way,
shouldn't it?  The appropiate places are

      ipc/shm.c::shm_swap_in()
      mm/page_alloc.c::swap_in()

and the old place of the old age_page():

      mm/vmscan.c::try_to_swap_out()

together with some unused variables out of

      include/linux/sched.h::task_struct (e.g. dec_flt)
      include/linux/sched.h::struct page (e.g. unused :-)

nothing more is needed due to the better swap cache of
2.1.129 in comparision to 2.0.36.


          Werner

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

  reply	other threads:[~1998-11-20 12:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.3.95.981119002335.838A-100000@penguin.transmeta.com>
1998-11-19 21:34 ` Linux-2.1.129 Dr. Werner Fink
1998-11-19 21:58   ` Linux-2.1.129 Rik van Riel
1998-11-20 12:09     ` Dr. Werner Fink [this message]
1998-11-19 22:33   ` Linux-2.1.129 Linus Torvalds
1998-11-23 17:13     ` Linux-2.1.129 Stephen C. Tweedie
1998-11-23 19:16       ` Linux-2.1.129 Eric W. Biederman
1998-11-23 20:02         ` Linux-2.1.129 Linus Torvalds
1998-11-23 21:25           ` Linux-2.1.129 Rik van Riel
1998-11-23 22:19           ` Linux-2.1.129 Dr. Werner Fink
1998-11-24  3:37           ` Linux-2.1.129 Eric W. Biederman
1998-11-24 15:25           ` Linux-2.1.129 Stephen C. Tweedie
1998-11-24 17:33             ` Linux-2.1.129 Linus Torvalds
1998-11-24 19:59               ` Linux-2.1.129 Rik van Riel
1998-11-24 20:45                 ` Linux-2.1.129 Linus Torvalds
1998-11-25 14:19               ` Linux-2.1.129 Stephen C. Tweedie
1998-11-25 21:07                 ` Linux-2.1.129 Eric W. Biederman
1998-11-26 12:57                   ` Linux-2.1.129 Stephen C. Tweedie
1998-11-25 20:33             ` Linux-2.1.129 Zlatko Calusic
1998-11-23 19:46       ` Linux-2.1.129 Eric W. Biederman
1998-11-23 21:18         ` Linux-2.1.129 Rik van Riel
1998-11-24  6:28           ` Linux-2.1.129 Eric W. Biederman
1998-11-24  7:56             ` Linux-2.1.129 Rik van Riel
1998-11-24 15:48             ` Linux-2.1.129 Stephen C. Tweedie
1998-11-24 15:38         ` Linux-2.1.129 Stephen C. Tweedie
1998-11-23 20:12       ` Linux-2.1.129 Rik van Riel
1998-11-23 20:53       ` Running 2.1.129 at extrem load [patch] (Was: Linux-2.1.129..) Dr. Werner Fink
1998-11-23 21:59         ` Rik van Riel
1998-11-23 22:35           ` Dr. Werner Fink
1998-11-24 12:38             ` Dr. Werner Fink

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=19981120130948.20965@boole.suse.de \
    --to=werner@suse.de \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --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