linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "David S. Miller" <davem@redhat.com>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: page_launder() bug
Date: Sun, 13 May 2001 13:42:18 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.21.0105131330350.20613-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0105131637060.5468-100000@imladris.rielhome.conectiva>


On Sun, 13 May 2001, Rik van Riel wrote:
> > 
> > The high-level VM layer simply doesn't have that kind of information.
> 
> Agreed.  I'd like to make sure, however, that we keep the
> high-level VM cleanly separated from the lower layers so
> we can keep the VM maintainable and predictable...

This is by far my biggest issue.

This is also why I much prefer to not have page_launder() know about swap
counts and issues like that - adding logic to page_launder() to find and
dismiss dead swap pages would have been the straightforward approach, but
would have made swap more special than I think it is.

Right now I'm _fairly_ happy with how generic the page cache handling is,
and how swapping and shared memory are much better integrated in the
overall design than they used to be. Swapping (and especially shared
memory) used to be a ratsnest of special cases, with magic function calls
and innate knowledge of how things worked by the core VM code.

These days, the page cache and the notion of "address spaces" have taken
up a lot of the special case logic, and most of it is gone. I'm looking
forward to the day when we could drop the "PG_swapcache" bit in the page
flags structure, and not have any special logic for swapping at
all.

Already some of these special cases are really unnecessary, and could
validly be replaced with checking for mapping matches instead. See for
example the lonely use in mm/filemap.c - it would make more sense to
verify that "page->mapping == mapping" instead of testing a
special-purpose bit: suddenly __find_get_swapcache_page and
__find_get_page actually end up doing pretty much the same thing.

It's not worth doing those kinds of small details now, but what I want to
have in the long run is to have _less_ special cases for swapping etc -
we've already pretty clearly shown that swapping isn't really anything
different from shared mappings, it's just a different allocation strategy.

And that's why I'd rather have generic support for _any_ page mapping that
wants to drop pages early than have specific logic for swapping.
Historically, we've always had very good results from trying to avoid
having special cases and instead trying to find what the common rules
might be.

			Linus


  reply	other threads:[~2001-05-13 20:42 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-06 21:08 page_launder() bug BERECZ Szabolcs
2001-05-06 21:59 ` Jonathan Morton
2001-05-06 22:07   ` BERECZ Szabolcs
2001-05-07  4:55 ` David S. Miller
2001-05-07  5:19   ` Aaron Lehmann
2001-05-07  6:26   ` Tobias Ringstrom
2001-05-07  8:59     ` Helge Hafting
2001-05-07 19:02       ` J . A . Magallon
2001-05-08  7:52         ` Helge Hafting
2001-05-10 12:19           ` Ingo Oeser
2001-05-10 10:51         ` Anuradha Ratnaweera
2001-05-07 10:52     ` Alan Cox
2001-05-07 13:49     ` Daniel Phillips
2001-05-07 13:53     ` H. Peter Anvin
2001-05-07  8:54   ` David S. Miller
2001-05-07 15:12     ` Tobias Ringstrom
2001-05-07 14:52   ` Horst von Brand
     [not found]     ` <davem@redhat.com>
2001-11-21  7:16       ` [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode Jeff V. Merkey
2001-11-21  6:22         ` David S. Miller
2001-11-21  6:47           ` David S. Miller
2001-11-21  6:54             ` Jeff Merkey
2001-11-21  6:56             ` David S. Miller
2001-11-21  7:03               ` Jeff Merkey
2001-11-21  7:49                 ` arjan
2001-11-21 18:31                   ` Jeff Merkey
2001-11-21 19:06                     ` Doug Ledford
2001-11-21 19:51                       ` Jeff Merkey
2001-11-21 19:58                         ` J Sloan
2001-11-21 20:38                         ` Doug Ledford
2001-11-21 21:17                           ` Jeff Merkey
2001-11-21 19:16                     ` Arjan van de Ven
2001-11-21 19:53                       ` Jeff Merkey
2001-11-21 20:36                         ` Doug Ledford
2001-11-21 21:16                           ` Jeff Merkey
2001-11-21 21:28                           ` Robert Love
2001-11-21  7:09               ` David S. Miller
2001-11-21  7:14                 ` Jeff Merkey
2001-11-21  7:28               ` Stuart Young
2001-11-21  7:33           ` Jeff V. Merkey
2001-11-21  6:54             ` Chris Abbey
2001-11-21  7:05               ` Jeff Merkey
2001-11-21  6:47         ` Kai Henningsen
2001-11-21 18:28           ` Jeff Merkey
2001-11-21  8:49         ` Alan Cox
2001-11-21 18:28           ` Jeff Merkey
2001-05-08 17:59   ` page_launder() bug Kai Henningsen
2001-05-09  2:32   ` Rusty Russell
2001-05-09  8:43     ` Martin Dalecki
2001-05-09  3:36   ` Jonathan Morton
2001-05-07 17:59 ` Linus Torvalds
2001-05-07 21:22   ` Marcelo Tosatti
2001-05-07 23:23     ` Linus Torvalds
2001-05-07 21:50       ` Marcelo Tosatti
2001-05-07 23:52         ` Linus Torvalds
2001-05-07 22:26           ` Marcelo Tosatti
2001-05-08  2:29             ` Linus Torvalds
2001-05-13 16:08               ` Rik van Riel
2001-05-13 19:29                 ` Linus Torvalds
2001-05-14 22:05                   ` Marcelo Tosatti
2001-05-08  0:16           ` David S. Miller
2001-05-08  2:34             ` Linus Torvalds
2001-05-08  1:40               ` Marcelo Tosatti
2001-05-08  3:46                 ` Linus Torvalds
2001-05-08  2:37                   ` Marcelo Tosatti
2001-05-08 21:16                   ` Marcelo Tosatti
2001-05-08 23:38                     ` Linus Torvalds
2001-05-08 23:53                       ` Marcelo Tosatti
2001-05-09  2:13                       ` David S. Miller
2001-05-09 17:38                         ` Marcelo Tosatti
2001-05-09 20:05                         ` David S. Miller
2001-05-09 18:40                           ` Marcelo Tosatti
2001-05-09 21:08                           ` David S. Miller
2001-05-09 19:50                             ` Marcelo Tosatti
2001-05-13 16:34                         ` Rik van Riel
2001-05-13 19:34                           ` Linus Torvalds
2001-05-13 19:39                             ` Rik van Riel
2001-05-13 20:42                               ` Linus Torvalds [this message]
2001-05-14  7:05                                 ` Kai Henningsen
2001-05-13 17:52                         ` David S. Miller
2001-05-13 17:55                           ` Rik van Riel
2001-05-13 18:00                           ` David S. Miller
2001-05-08  6:50                 ` David S. Miller
2001-05-08  7:40                   ` Linus Torvalds
2001-05-08 18:53                     ` Marcelo Tosatti
2001-05-08  8:29                   ` David S. Miller
2001-05-08  3:22               ` David S. Miller
2001-05-08  3:26                 ` Linus Torvalds
2001-05-08  2:47             ` David S. Miller
2001-05-08  1:34               ` Marcelo Tosatti
2001-05-08  3:18               ` David S. Miller
2001-05-08  1:47                 ` Marcelo Tosatti
2001-05-08  3:24                 ` Linus Torvalds
2001-05-08  3:29                 ` David S. Miller
2001-05-08 10:36                   ` BERECZ Szabolcs
2001-05-08 12:33             ` Mikulas Patocka
2001-05-13 16:24               ` Rik van Riel
2001-05-13 21:02                 ` Another VM race? (was: page_launder() bug) Mikulas Patocka
2001-05-13 23:04                   ` Rik van Riel
2001-05-14  9:53                     ` Mikulas Patocka
2001-05-08  0:06         ` page_launder() bug David S. Miller
2001-05-07 23:31     ` David S. Miller
2001-05-07 22:44 ` David S. Miller
2001-05-08  1:00   ` Horst von Brand
2001-05-07  0:32 Jonathan Lundell

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.0105131330350.20613-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=riel@conectiva.com.br \
    /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).