From: Rajagopal Ananthanarayanan <ananth@sgi.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: riel@nl.linux.org, Kanoj Sarcar <kanoj@google.engr.sgi.com>,
linux-mm@kvack.org, "David S. Miller" <davem@redhat.com>
Subject: 7-4 VM killing (A solution)
Date: Thu, 04 May 2000 17:47:30 -0700 [thread overview]
Message-ID: <39121A22.BA0BA852@sgi.com> (raw)
In-Reply-To: Pine.LNX.4.10.10005041517310.878-100000@penguin.transmeta.com
Linus Torvalds wrote:
>
> On Thu, 4 May 2000, Rajagopal Ananthanarayanan wrote:
> >
> > One clarification: In the case I reported only
> > dbench was running, presumably doing a lot of read/write. So, why
> > isn't shrink_mmap able to find freeable pages? Is it because
> > the shrink_mmap() is too conservative about implementing LRU?
>
> Probably. One of the things that has changed is exactly _which_ pages are
> on the LRU list, so the old heuristics from shrink_mmap() may need some
> tweaking too. In fact, as with vmscan, we should probably scan the LRU
> list at least _twice_ when the priority level reaches zero (in order to
> defeat the aging).
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;
count--;
/* Page not used -> free it or put it on the old list
* so it gets freed first the next time */
if (TryLockPage(page))
goto dispose_continue;
[ ... ]
-------------------
With this I'm able to run dbench upto 16 threads (using over
0.5 GB of disk). For reference, without the fix,
dbench wouldn't run even with as few as 4 threads (using
much less disk space).
>
> This is also an area where the secondary effects of the vmscan page
> lockedness changes could start showing up - the page being locked on the
> LRU list makes a difference to the shrink_mmap() algorithm..
>
> Linus
Kanoj & I looked over your changes (lot easier to do over
the phone!) ... and didn't find any thing wrong with it.
Again, with the above fix things look good. Since
7-4 is badly broken in this respect, do you want a patch?
Since it is a small change, you can put it in "by hand" ...
--
--------------------------------------------------------------------------
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 0: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 ` Rajagopal Ananthanarayanan [this message]
2000-05-05 1:30 ` 7-4 VM killing (A solution) Rik van Riel
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=39121A22.BA0BA852@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 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.