linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrea Arcangeli <andrea@e-mind.com>
Cc: "Eric W. Biederman" <ebiederm+eric@ccr.net>, linux-mm@kvack.org
Subject: Re: [PATCH] dirty pages in memory & co.
Date: Tue, 11 May 1999 19:45:40 +0100 (BST)	[thread overview]
Message-ID: <14136.31444.33068.416501@dukat.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.05.9905111334580.929-100000@laser.random>

Hi,

On Tue, 11 May 1999 13:38:48 +0200 (CEST), Andrea Arcangeli
<andrea@e-mind.com> said:

> But I am worried by page faults. The page fault that allow us to know
> where there is an uptodate swap-entry on disk just hurt performances more
> than not having such information (I did benchmarks).

It obviously depends on whether you are swap-bound or CPU-bound.  Have
you tried both?

One thing I definitely agree with is that it may sometimes be preferable
to drop the swap cache to avoid fragmentation.  If we have a new dirty
page requiring writing to swap, and its VA neighbours are already in the
swap cache, it makes sense to eliminate the swap cache and write all the
pages to the new location to keep them contiguous on disk.  

The real aim here is to allow us to keep dirty pages in the swap cache
too: this will allow us to keep good, unfragmented swap allocations by
persistently assigning a contiguous range of swap to a contiguous range
of process data pages, even if the process is only dirtying some of
those pages.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

  reply	other threads:[~1999-05-11 18:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-05-07 14:56 Eric W. Biederman
1999-05-10  0:57 ` Andrea Arcangeli
1999-05-11  1:06   ` Eric W. Biederman
1999-05-11 11:38     ` Andrea Arcangeli
1999-05-11 18:45       ` Stephen C. Tweedie [this message]
1999-05-10 19:37 ` Stephen C. Tweedie
1999-05-10 21:01   ` Benjamin C.R. LaHaise
1999-05-10 23:43     ` Stephen C. Tweedie
1999-05-11  0:30   ` Eric W. Biederman

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=14136.31444.33068.416501@dukat.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=andrea@e-mind.com \
    --cc=ebiederm+eric@ccr.net \
    --cc=linux-mm@kvack.org \
    /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