From: Rik van Riel <riel@conectiva.com.br>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Juan J. Quintela" <quintela@fi.udc.es>, linux-mm@kvack.org
Subject: Re: PATCH: Possible solution to VM problems (take 2)
Date: Sun, 21 May 2000 16:02:45 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.21.0005211556390.9939-100000@duckman.distro.conectiva> (raw)
In-Reply-To: <Pine.LNX.4.10.10005211005430.1320-100000@penguin.transmeta.com>
On Sun, 21 May 2000, Linus Torvalds wrote:
> On Sun, 21 May 2000, Rik van Riel wrote:
> >
> > The only change we may want to do is completely drop
> > the priority argument from swap_out since:
> > - if we fail through to swap_out we *must* unmap some pages
>
> Getting rid of the priority argument to swap_out() would mean
> that swap_out() can no longer make any decisions of its own.
> Suddenly swap_out() is a slave to shrink_mmap(), and is not
> allowed to say "there's a lot of pressure on the VM system right
> now, I can't free anything up at this moment, maybe there could
> be some dirty buffers you could write out instead?".
OK, you're right here.
> > - we really want do_try_to_free_pages to succeed every time
>
> Well, we do want that, but at the same time we also do want it to
> recognize when it really isn't making any progress.
>
> When our priority level turns to "Give me some pages or I'll
> rape your wife and kill your children", and _still_ nobody gives
> us memory, we should just realize that we should give up.
Problem is that the current code seems to give up way
before that. We should be able to free memory from mmap002
no matter what, because we *can* (the backing store for
the data exists).
IMHO it is not acceptable that do_try_to_free_pages() can
fail on the mmap002, but you are completely right that my
quick and dirty idea is wrong.
(I'll steal davem's code and split the current lru queue
in active, inactive and laundry, then the system will
know which page to steal, how to do effective async IO
- don't wait for pages if we have inactive pages left,
but wait for laundry pages instead of stealing active
ones - and when it *has* to call swap_out)
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-21 19:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-16 19:32 [dirtypatch] quickhack to make pre8/9 behave (fwd) Rik van Riel
2000-05-17 0:28 ` PATCH: less dirty (Re: [dirtypatch] quickhack to make pre8/9 behave (fwd)) Juan J. Quintela
2000-05-17 20:45 ` PATCH: Possible solution to VM problems Juan J. Quintela
2000-05-17 23:31 ` PATCH: Possible solution to VM problems (take 2) Juan J. Quintela
2000-05-18 0:12 ` Juan J. Quintela
2000-05-18 1:07 ` Rik van Riel
2000-05-21 8:14 ` Linus Torvalds
2000-05-21 16:01 ` Rik van Riel
2000-05-21 17:15 ` Linus Torvalds
2000-05-21 19:02 ` Rik van Riel [this message]
2000-05-22 11:27 ` PATCH: Balancing patch against pre9-3 Quintela Carreira Juan J.
-- strict thread matches above, loose matches on Subject: below --
2000-05-18 5:58 PATCH: Possible solution to VM problems (take 2) Neil Schemenauer
2000-05-14 9:48 Summary of recent VM behavior [2.3.99-pre8] Craig Kulesa
2000-05-18 10:17 ` PATCH: Possible solution to VM problems (take 2) Craig Kulesa
2000-05-18 10:59 ` Jan Niehusmann
2000-05-18 13:41 ` Rik van Riel
2000-05-18 13:49 ` Stephen C. Tweedie
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.0005211556390.9939-100000@duckman.distro.conectiva \
--to=riel@conectiva.com.br \
--cc=linux-mm@kvack.org \
--cc=quintela@fi.udc.es \
--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