From: Rik van Riel <riel@conectiva.com.br>
To: Rajagopal Ananthanarayanan <ananth@sgi.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Kanoj Sarcar <kanoj@google.engr.sgi.com>,
linux-mm@kvack.org, "David S. Miller" <davem@redhat.com>
Subject: Re: 7-4 VM killing (A solution)
Date: Thu, 4 May 2000 22:30:35 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.21.0005042227540.28833-100000@duckman.conectiva> (raw)
In-Reply-To: <39121A22.BA0BA852@sgi.com>
On Thu, 4 May 2000, Rajagopal Ananthanarayanan wrote:
> Ok, I may have a solution after having asked, mostly to myself,
> why doesn't shrink_mmap() find pages to free?
>
> The answer apparenlty is because in 7-4 shrink_mmap(),
> unreferenced pages get filed as "young" if the zone has
> enough pages in it (free_pages > pages_high).
>
> Because of this bug, if we examine a zone which already
> has enough free pages, all referenced pages now go to
> the "back" of the lru list.
>
> On a subsequent scan, we may never get to these pages in time.
> Comments?
>
> Here's the new code to shrink_mmap:
>
> ------------
> [ ... ]
> dispose = &young;
> if (test_and_clear_bit(PG_referenced, &page->flags))
> goto dispose_continue;
>
> if (!page->buffers && page_count(page) > 1)
> goto dispose_continue;
>
> dispose = &old;
> if (p_zone->free_pages > p_zone->pages_high)
> goto dispose_continue;
I've tried this variant (a few weeks ago, before submitting
the current code to Linus) and have found a serious bug in
it.
If we put all the unreferenced pages from one zone (with
enough free pages) on the front of the queue, a subsequent
run will not make it to the pages of the zone which needs
to have pages freed currently...
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-05-05 1:30 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8ener4$6djpb$1@fido.engr.sgi.com>
2000-05-03 3:11 ` Oops in __free_pages_ok (pre7-1) (Long) (backtrace) Rajagopal Ananthanarayanan
2000-05-03 3:47 ` Linus Torvalds
2000-05-03 5:26 ` Kanoj Sarcar
2000-05-03 6:22 ` Rajagopal Ananthanarayanan
2000-05-03 16:11 ` Kanoj Sarcar
2000-05-03 16:19 ` Linus Torvalds
2000-05-03 16:35 ` Kanoj Sarcar
2000-05-03 17:16 ` Linus Torvalds
2000-05-03 17:31 ` Kanoj Sarcar
2000-05-03 18:17 ` Linus Torvalds
2000-05-03 18:37 ` Rajagopal Ananthanarayanan
2000-05-03 18:37 ` Kanoj Sarcar
2000-05-03 19:41 ` Rajagopal Ananthanarayanan
2000-05-03 21:28 ` Jeff Garzik
2000-05-03 8:11 ` Linus Torvalds
2000-05-03 8:31 ` Linus Torvalds
2000-05-03 16:08 ` Kanoj Sarcar
2000-05-03 16:14 ` Linus Torvalds
2000-05-03 16:24 ` Kanoj Sarcar
2000-05-04 1:38 ` Linus Torvalds
2000-05-04 2:44 ` Rajagopal Ananthanarayanan
2000-05-04 4:05 ` Linus Torvalds
2000-05-04 3:16 ` Rajagopal Ananthanarayanan
2000-05-04 4:10 ` Linus Torvalds
2000-05-05 4:46 ` Rajagopal Ananthanarayanan
2000-05-04 7:42 ` Rajagopal Ananthanarayanan
2000-05-04 15:33 ` Linus Torvalds
2000-05-04 15:57 ` Rik van Riel
2000-05-04 17:19 ` Rajagopal Ananthanarayanan
2000-05-04 17:41 ` Rik van Riel
2000-05-04 18:18 ` Rajagopal Ananthanarayanan
2000-05-04 18:43 ` Linus Torvalds
2000-05-04 19:00 ` Rik van Riel
2000-05-04 19:17 ` Linus Torvalds
2000-05-04 21:16 ` Rajagopal Ananthanarayanan
2000-05-04 21:51 ` Rik van Riel
2000-05-04 22:21 ` Linus Torvalds
2000-05-05 0:47 ` 7-4 VM killing (A solution) Rajagopal Ananthanarayanan
2000-05-05 1:30 ` Rik van Riel [this message]
2000-05-05 1:47 ` Rajagopal Ananthanarayanan
2000-05-05 5:13 ` Linus Torvalds
2000-05-05 6:44 ` Rajagopal Ananthanarayanan
2000-05-05 6:51 ` Linus Torvalds
2000-05-05 10:23 ` Rik van Riel
2000-05-04 20:40 ` Oops in __free_pages_ok (pre7-1) (Long) (backtrace) Roger Larsson
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.0005042227540.28833-100000@duckman.conectiva \
--to=riel@conectiva.com.br \
--cc=ananth@sgi.com \
--cc=davem@redhat.com \
--cc=kanoj@google.engr.sgi.com \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.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