linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Ben LaHaise <bcrl@redhat.com>,
	Rik van Riel <riel@conectiva.com.br>,
	Richard Jerrrell <jerrell@missioncriticallinux.com>,
	Stephen Tweedie <sct@redhat.com>,
	arjanv@redhat.com, alan@redhat.com, linux-mm@kvack.org
Subject: Re: [PATCH] swap_state.c thinko
Date: Fri, 6 Apr 2001 17:31:30 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0104061638200.1098-100000@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.31.0104051727490.1149-100000@penguin.transmeta.com>

On Thu, 5 Apr 2001, Linus Torvalds wrote:
> 
> I'd prefer something more along these lines: it gets rid of
> free_page_and_swap_cache() altogether, along with "is_page_shared()",
> realizing that "is_page_shared()" was only validly used on swap-cache
> pages anyway and thus getting rid of the generic tests it had for other
> kinds of pages.

I like this direction, but (if I understand the issues better today
than I did yesterday) the patch you posted looks seriously incomplete
to me.  While it deals with one of the issues raised by Rich Jerrell
(writing dead swap pages), doesn't it exacerbate his other issue?

That after a process exits (unmaps), if a page was in the swap cache,
its swap slot will remain allocated until vmscan.c gets to deal with it;
which would be okay, except that vm_enough_memory() may give false
negatives meanwhile, because there's no count of such pages (and Rich
gave the nice example that immediately starting up the same program
again was liable to fail because of this).  Exacerbates, because
that problem was just on the !pte_present entries, now with your
patch it would be on the pte_present entries too.

But I don't agree with the way Rich adds his nr_swap_cache_pages to
"free" in his vm_enough_memory(), because cached pages are all already
counted into "free" from page_cache_size - so I believe he's double-
accounting all the swap cache pages as free, when it should just be
those which (could) have been freed on exit/unmap.  And to count those,
I think you'd have to reinstate code like free_page_and_swap_cache().

Instead, perhaps vm_enough_memory() should force a scan to free
before failing?  And would need to register its own memory pressure,
so the scan tries hard enough to provide what will be needed?

Sorry, we've moved well away from Ben's "swap_state.c thinko".

Hugh

--
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/

  reply	other threads:[~2001-04-06 16:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-05 15:56 Ben LaHaise
2001-04-05 16:05 ` Rik van Riel
2001-04-05 17:11   ` Ben LaHaise
2001-04-05 23:40     ` Andrea Arcangeli
2001-04-06  0:32     ` Linus Torvalds
2001-04-06 16:31       ` Hugh Dickins [this message]
2001-04-06 17:21         ` Linus Torvalds
2001-04-06 18:23           ` Hugh Dickins
2001-04-06 18:57             ` Linus Torvalds
2001-04-06 19:06               ` Rik van Riel
2001-04-06 18:47           ` Andrea Arcangeli
2001-04-06 18:37             ` Hugh Dickins
2001-04-06 19:09               ` Andrea Arcangeli
2001-04-06 18:53                 ` Hugh Dickins
2001-04-06 19:14                 ` Andrea Arcangeli
2001-04-06 19:03                   ` Hugh Dickins
2001-04-06 20:03                     ` Andrea Arcangeli
2001-04-06 19:12               ` Richard Jerrell
2001-04-06 19:52               ` Linus Torvalds
2001-04-06 20:22                 ` Andrea Arcangeli
2001-04-06 21:04                   ` Rik van Riel
2001-04-07  1:27                     ` Andrea Arcangeli
2001-04-09 18:16                   ` Alan Cox
2001-04-09 18:45                     ` Andrea Arcangeli
2001-04-09 20:32                     ` Linus Torvalds
2001-04-09 20:54                       ` David L. Parsley
2001-04-10 21:07                       ` James Antill
2001-04-10 22:20                         ` Jeff Garzik
2001-04-06 20:48                 ` Hugh Dickins
2001-04-05 17:21 ` Hugh Dickins
2001-04-05 21:39   ` Richard Jerrell
2001-04-06 20:20 Bulent Abali
2001-04-06 20:33 ` Jeff Garzik

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.0104061638200.1098-100000@localhost.localdomain \
    --to=hugh@veritas.com \
    --cc=alan@redhat.com \
    --cc=arjanv@redhat.com \
    --cc=bcrl@redhat.com \
    --cc=jerrell@missioncriticallinux.com \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.com \
    --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