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
next prev parent reply other threads:[~1998-11-20 12:11 UTC|newest]
Thread overview: 30+ 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
1998-11-19 19:22 Linux-2.1.129 David S. Miller
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.