From: Rajagopal Ananthanarayanan <ananth@sgi.com>
To: riel@nl.linux.org
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, 04 May 2000 18:47:32 -0700 [thread overview]
Message-ID: <39122834.DA7FEDFF@sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0005042227540.28833-100000@duckman.conectiva>
Rik van Riel wrote:
>
> 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...
>
The only reason why pages should be moved to the tail
of the lru list is when they are referenced, and may be
if they have high page->count.
Pages in zones with enough free memory should not be re-ordered.
Such pages should not control the iterations of shrink_mmap.
The unreferenced pages currently at the front of the lru
queue are the ones that we should free first anyway. Just because
the corresponding zone has enough free memory in it, the
relative order does not change. Are you talking about these
pages adding up against "count" in shrink_mmap?
On a more practical note, how does your bug manifest?
What does not run, or does not run better?
--
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------
--
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:47 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
2000-05-05 1:47 ` Rajagopal Ananthanarayanan [this message]
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=39122834.DA7FEDFF@sgi.com \
--to=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