linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo@conectiva.com.br>
To: linux-mm@kvack.org
Subject: [RFC] some experimental VM code
Date: Tue, 5 Jun 2001 21:31:01 -0300 (BRT)	[thread overview]
Message-ID: <Pine.LNX.4.21.0106052108440.3769-100000@freak.distro.conectiva> (raw)

Hi people, 

As you may know, the current behaviour of the kernel when it hits a
low memory condition is to allow each task to:

 - Writeout data to free memory
 - Unmap pte's/allocate swap space and age down pages

Until the task gets a free page. 

I've been saying for sometime now that I think only kswapd should do
the page aging part. If we don't do it this way, heavy VM loads will make
each memory intensive task age down other processes pages, so we see
ourselves in a "unmapping/faulting" storm. Imagine what happens to
interactivity in such a case. 

Trying to avoid that bad behaviour, I've experimented some code which 

 - Makes only kswapd age pages/unmap pte's. 
 - Tasks doing __GFP_IO allocations (non GFP_BUFFER allocations) wait on 
   the kswapd waitqueue when they are not able to do any progress trying
   to free pages themselves.
 - kswapd will not sleep until there is an inactive shortage or a free
   shortage.

Plus some other tweaks.

The behaviour is far away from getting nice, but I believe this is a step
on the right direction.

I _really_ would like to receive reports on this patch --- interactivity
under high loads should be quite better with it.

http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.6pre1/2.4.6pre1-vm-mt.patch

--
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-mm.org/

                 reply	other threads:[~2001-06-06  2:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=Pine.LNX.4.21.0106052108440.3769-100000@freak.distro.conectiva \
    --to=marcelo@conectiva.com.br \
    --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