linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Rik van Riel <riel@nl.linux.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel <linux-kernel@vger.rutgers.edu>,
	Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH] 2.2.1{3,4,5} VM fix
Date: Thu, 20 Jan 2000 18:11:46 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.21.0001200433150.2314-100000@alpha.random> (raw)
In-Reply-To: <Pine.LNX.4.10.10001192201020.15862-100000@mirkwood.dummy.home>

On Wed, 19 Jan 2000, Rik van Riel wrote:

>--- linux-2.2.15-pre3/mm/vmscan.c.orig	Wed Jan 19 21:18:54 2000
>+++ linux-2.2.15-pre3/mm/vmscan.c	Wed Jan 19 22:06:34 2000
>@@ -490,12 +490,13 @@
> 		{
> 			if (do_try_to_free_pages(GFP_KSWAPD))
> 			{
>+				run_task_queue(&tq_disk);
> 				if (tsk->need_resched)
> 					schedule();
> 				continue;
> 			}

There's a limit of max swap request, after that a wait_on_page will
trigger I/O. So you'll only decrease performance by doing so as far I can 
tell.

> 			tsk->state = TASK_INTERRUPTIBLE;
>-			schedule_timeout(10*HZ);
>+			schedule_timeout(HZ);

I used 10 sec because if you run oom into kswapd it means you can't hardly
do anything within kswapd in the next 10 seconds. If userspace is
triggering OOM all will continue to run fine and it's way better to remove
kswapd from the game to gracefully allow userspace to detect oom. Note
that a do_try_to_free_pages can take quite some time before failing in a
9giga machine with 9giga allocated in userspace (I am talking 2.2.x, in
2.3.x my page-LRU will allow shrink_mmap to not waste time trying to free
9giga/PAGE_SIZE pages).

If instead atomic allocations caused oom and kswapd failed then you should
give up for some time as well since you know all memory is not freeable
and so only a __free_pages will release memory. Thus kswapd will be
wasted time in such case too and you should instead wait a process to
trigger some allocation to be able to kill it.

> 	wake_up_interruptible(&kswapd_wait);
>-	if (gfp_mask & __GFP_WAIT)
>+	if ((gfp_mask & __GFP_WAIT) && (nr_free_pages < (freepages.low - 4)))
> 		retval = do_try_to_free_pages(gfp_mask);

-4 make no sense as ".low" could be as well set to 3 and theorically the
system should remains stable.

And you are trying to wakeup kswapd instead of blocking. This will make
oom condition worse and it brekas my trashing mem watermark heuristic. The
heuristic is necessary to penalize the hog. It should be a per-process
thing btw.

>--- linux-2.2.15-pre3/mm/page_alloc.c.orig	Wed Jan 19 21:32:05 2000
>+++ linux-2.2.15-pre3/mm/page_alloc.c	Wed Jan 19 21:42:00 2000
>@@ -212,7 +212,7 @@
> 	if (!(current->flags & PF_MEMALLOC)) {
> 		int freed;
> 
>-		if (nr_free_pages > freepages.min) {
>+		if (nr_free_pages > freepages.low) {
> 			if (!low_on_memory)
> 				goto ok_to_allocate;
> 			if (nr_free_pages >= freepages.high) {

freepages.low is unused. With this change you are using low and making min
unused. min seems the right name there. Nobody is allowed to allocate
memory without first free some memory if the system is under the
_min_ memory watermark. If you don't like the current defaults just change
the dyanmic setting at boot in page_alloc.c. They can be changed as well
via /proc/sys/vm/freepages (you just know :).

Andrea

--
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.nl.linux.org/Linux-MM/

  reply	other threads:[~2000-01-20 17:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-19 21:15 Rik van Riel
2000-01-20 17:11 ` Andrea Arcangeli [this message]
2000-01-20 20:30   ` Rik van Riel
2000-01-21  0:42     ` Andrea Arcangeli
2000-01-21  0:56       ` Alan Cox
2000-01-21  2:08         ` Andrea Arcangeli
2000-01-21  2:43           ` Rik van Riel
2000-01-21 12:54             ` Andrea Arcangeli
2000-01-21 19:18               ` Rik van Riel
2000-01-22  2:43                 ` Andrea Arcangeli
2000-01-22  3:22                   ` Benjamin C.R. LaHaise
2000-01-22 14:02                     ` Andrea Arcangeli
2000-01-24 13:21                       ` GFP_XXX semantics (was: Re: [PATCH] 2.2.1{3,4,5} VM fix) Ingo Oeser
2000-01-24 15:08                         ` Andrea Arcangeli
2000-01-25  0:01                           ` Rik van Riel
     [not found]                       ` <Pine.LNX.4.10.10001241411310.24852-100000@nightmaster.csn. tu-chemnitz.de>
2000-01-24 13:40                         ` Andi Kleen
2000-01-21  1:12       ` [PATCH] 2.2.1{3,4,5} VM fix Rik van Riel
2000-01-21  2:01         ` Andrea Arcangeli
2000-01-21  2:36           ` Andrea Arcangeli
2000-01-21  2:37           ` Rik van Riel
2000-01-21 13:24             ` Andrea Arcangeli

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.0001200433150.2314-100000@alpha.random \
    --to=andrea@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=riel@nl.linux.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