From: Marcelo Tosatti <marcelo@conectiva.com.br>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Date: Mon, 17 Sep 2001 23:25:09 -0300 (BRT) [thread overview]
Message-ID: <Pine.LNX.4.21.0109172314130.7032-100000@freak.distro.conectiva> (raw)
In-Reply-To: <20010918053711.P698@athlon.random>
On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> On Mon, Sep 17, 2001 at 10:08:22PM -0300, Marcelo Tosatti wrote:
> >
> >
> > On Mon, 17 Sep 2001, Marcelo Tosatti wrote:
> >
> > >
> > >
> > > On Mon, 17 Sep 2001, Linus Torvalds wrote:
> > >
> > > >
> > > > Ok, the big thing here is continued merging, this time with Andrea.
> > > >
> > > > I still don't like some of the VM changes, but integrating Andrea's VM
> > > > changes results in (a) better performance and (b) much cleaner inactive
> > > > page handling in particular. Besides, for the 2.4.x tree, the big priority
> > > > is stability, we can re-address my other concerns during 2.5.x.
> > >
> > > Andrea,
> > >
> > > Could you please make a resume of your VM changes ?
> > >
> > > Its hard to keep up with VM changes this way.
> >
> > Andrea,
> >
> > I've just read a bit of your new VM code and I have a few comments.
> >
> > You completly removed the "inactive freeable pages" logic: There is no
>
> yes, it wasn't relly useful to keep this list lazily, you either keep it
> enforced with locking overhead or such information isn't valuable.
>
> > more distiction between "freeable inactive" and "free" pages. All VM work
> > is based on "freepages.high" watermark. I don't like that: it seems to
>
> hardly on freepages.high:
>
> diff -urN vm-ref/mm/swap.c vm/mm/swap.c
> --- vm-ref/mm/swap.c Tue Sep 18 00:18:17 2001
> +++ vm/mm/swap.c Tue Sep 18 00:18:35 2001
> @@ -24,50 +24,13 @@
> #include <asm/uaccess.h> /* for copy_to/from_user */
> #include <asm/pgtable.h>
>
> -/*
> - * We identify three levels of free memory. We never let free mem
> - * fall below the freepages.min except for atomic allocations. We
> - * start background swapping if we fall below freepages.high free
> - * pages, and we begin intensive swapping below freepages.low.
> - *
> - * Actual initialization is done in mm/page_alloc.c
> - */
> -freepages_t freepages = {
> - 0, /* freepages.min */
> - 0, /* freepages.low */
> - 0 /* freepages.high */
> -};
> -
>
> > make page freeing more aggressive over time.
>
> I don't see your point with "page freeing more aggressive over time".
I meant "zone->freepages.high" (or something like that... you get the
idea).
My point is: we're not going to start aging pte's until we have a
zone shortage, right ?
With the old scheme, we would differentiate "inactive shortage" from "free
shortage".
>
> > Also, if we have several try_to_free_pages() callers, for different
> > classzones, I'm right saying that a caller with a "smaller" classzone can
> > "hide" pages in its "active_local_lru" and/or "inactive_local_lru" (during
> > shrink_cache) from other processes trying to free pages from those higher
> > zones ?
>
> I'm deeply impressed, you seem to have understood the rewrite greatly
> well, congrats, this "hiding" was infact my main concern I had on the
> memclass check during shrink_cache, but I don't think this will ever
> give us troubles. In such there are suprious swapouts with HIGHMEM
> we'll just need to waste some cpu by lefting those pages visible with a
> few changes in shrink_cache, but again I'm almost sure there won't be
> problems, we do multiple scans before failing so those pages will return
> visible before the other task has a chance to fail the allocation.
I really think this will cause problems in practice, Andrea.
Moreover, the whole active_local_lru has a _bad_ effect on writeout
clustering:
shrink_cache() callers on low classzone can "hide" pages from higher
classzone callers and avoid clustering. Look:
We have a nice big sequentially ordered list of pages to writeout.
lowzone shrink_cache() moves higher zones pages (from this ordered list)
to its inactive/active_local_lru until it calls schedule() (due to
need_resched()). (for example)
Now we have a higher classzone caller which finds "half of the block" and
writes it out.
>From this point on, we breaked in half an ordered list of pages which
could be nicely merged together at ll_rw_block().
The example I gave which splits one sequentially ordered list of pages in
two blocks is a simple and "stupid" one. But think how badly can we have
pages ordered during a long time of VM activity.
next prev parent reply other threads:[~2001-09-18 3:49 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-18 0:08 Linux 2.4.10-pre11 Linus Torvalds
2001-09-17 23:17 ` Marcelo Tosatti
2001-09-18 1:08 ` Marcelo Tosatti
2001-09-18 3:37 ` Andrea Arcangeli
2001-09-18 2:25 ` Marcelo Tosatti [this message]
2001-09-18 3:58 ` Andrea Arcangeli
2001-09-18 2:53 ` Marcelo Tosatti
2001-09-18 4:54 ` Andrea Arcangeli
2001-09-18 3:33 ` Marcelo Tosatti
2001-09-18 5:06 ` Andrea Arcangeli
2001-09-18 3:55 ` Marcelo Tosatti
2001-09-18 5:32 ` Andrea Arcangeli
2001-09-18 4:14 ` Marcelo Tosatti
2001-09-18 5:59 ` Andrea Arcangeli
2001-09-18 5:00 ` Marcelo Tosatti
[not found] ` <20010917211834.A31693@redhat.com>
[not found] ` <20010918035055.J698@athlon.random>
2001-09-18 2:02 ` Andrea Arcangeli
[not found] ` <20010917221653.B31693@redhat.com>
2001-09-18 2:27 ` Linus Torvalds
2001-09-18 3:14 ` Alan Cox
2001-09-18 3:26 ` Andrea Arcangeli
[not found] ` <20010918052201.N698@athlon.random>
2001-09-18 4:01 ` Benjamin LaHaise
2001-09-18 4:39 ` Andrea Arcangeli
2001-09-18 5:04 ` Alan Cox
2001-09-18 5:09 ` Andrea Arcangeli
2001-09-18 5:22 ` Benjamin LaHaise
2001-09-18 5:48 ` Andrea Arcangeli
2001-09-18 5:48 ` Andrew Morton
2001-09-18 6:11 ` Andrea Arcangeli
2001-09-18 5:02 ` Marcelo Tosatti
2001-09-18 6:40 ` Andrea Arcangeli
2001-09-18 16:06 ` Marcelo Tosatti
2001-09-18 19:18 ` Marcelo Tosatti
2001-09-18 21:05 ` Andrea Arcangeli
2001-09-19 13:57 ` Rik van Riel
2001-09-18 10:58 ` Martin Dalecki
2001-09-18 9:31 ` Alexander Viro
2001-09-18 9:39 ` Andrea Arcangeli
2001-09-18 9:44 ` Alexander Viro
2001-09-18 9:57 ` Andrea Arcangeli
2001-09-18 10:02 ` Alexander Viro
2001-09-18 10:17 ` Andrea Arcangeli
2001-09-18 10:28 ` Alexander Viro
2001-09-18 10:35 ` Andrea Arcangeli
2001-09-18 10:52 ` Alexander Viro
2001-09-18 11:05 ` Helge Hafting
2001-09-18 12:40 ` Andrea Arcangeli
2001-09-18 17:02 ` Linus Torvalds
2001-09-18 16:45 ` Linus Torvalds
2001-09-18 18:19 ` Alexander Viro
2001-09-18 18:27 ` Linus Torvalds
2001-09-18 19:14 ` Andreas Dilger
2001-09-18 19:41 ` Alexander Viro
2001-09-18 20:33 ` Richard Gooch
2001-09-18 20:53 ` Alexander Viro
2001-09-18 21:06 ` Richard Gooch
2001-09-18 21:27 ` Alexander Viro
2001-09-18 19:29 ` Benjamin LaHaise
2001-09-18 20:17 ` Stephan von Krawczynski
2001-09-18 20:33 ` Alan Cox
2001-09-19 13:42 ` Rik van Riel
2001-09-19 14:27 ` Alexander Viro
2001-09-19 2:59 ` Michael Peddemors
2001-09-19 16:11 ` Alexander Viro
2001-09-19 18:25 ` Andrea Arcangeli
2001-09-19 19:21 ` Alexander Viro
2001-09-19 20:55 ` Andrea Arcangeli
2001-09-19 21:17 ` Alexander Viro
2001-09-19 23:01 ` Andrea Arcangeli
2001-09-19 23:03 ` Andrea Arcangeli
2001-09-19 23:30 ` Alexander Viro
2001-09-19 23:40 ` Andrea Arcangeli
2001-09-20 13:56 ` Alexander Viro
2001-09-20 14:38 ` Chris Mason
2001-09-20 14:50 ` Alexander Viro
2001-09-20 15:44 ` Chris Mason
2001-09-20 16:43 ` Alexander Viro
2001-09-20 20:54 ` [PATCH] fs/block_dev.c cleanup Alexander Viro
2001-09-19 22:15 ` Linux 2.4.10-pre11 Richard Gooch
2001-09-20 2:34 ` Andrea Arcangeli
2001-09-20 10:52 ` Alexander Viro
2001-09-20 18:18 ` Andrea Arcangeli
2001-09-20 18:33 ` Alexander Viro
2001-09-20 18:59 ` Andrea Arcangeli
2001-09-20 20:41 ` Alexander Viro
2001-09-20 21:18 ` Andrea Arcangeli
2001-09-20 21:40 ` Alexander Viro
2001-09-20 22:13 ` Andrea Arcangeli
2001-09-20 22:20 ` Alexander Viro
2001-09-20 22:31 ` Andrea Arcangeli
2001-09-20 22:44 ` Alexander Viro
2001-09-20 23:03 ` Andrea Arcangeli
2001-09-20 23:11 ` Alexander Viro
2001-09-21 1:50 ` Alexander Viro
2001-09-21 2:42 ` Andrea Arcangeli
2001-09-21 3:47 ` Andrea Arcangeli
2001-09-21 4:00 ` Alexander Viro
2001-09-21 4:06 ` Andrea Arcangeli
2001-09-21 4:06 ` Andrea Arcangeli
2001-09-21 4:46 ` Andrea Arcangeli
2001-09-21 7:09 ` Andrea Arcangeli
2001-09-19 20:41 ` Richard Gooch
2001-09-19 13:38 ` Rik van Riel
2001-09-19 16:35 ` Andrea Arcangeli
2001-09-18 3:18 Ed Tomlinson
2001-09-18 2:31 ` Magnus Naeslund(f)
2001-09-18 2:49 ` David B. Stevens
2001-09-18 3:38 ` Ed Tomlinson
2001-09-18 3:15 ` Alan Cox
2001-09-18 4:41 ` H. Peter Anvin
2001-09-18 6:14 Alexei Podtelezhnikov
2001-09-18 13:51 ` Rik van Riel
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.0109172314130.7032-100000@freak.distro.conectiva \
--to=marcelo@conectiva.com.br \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).