public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Hugh Dickins <hugh@veritas.com>
Cc: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>,
	linux-kernel@vger.kernel.org, lhms-devel@lists.sourceforge.net
Subject: Re: [RFC] Changing COW detection to be memory hotplug friendly
Date: Mon, 14 Feb 2005 22:41:48 +0100	[thread overview]
Message-ID: <20050214214148.GM13712@opteron.random> (raw)
In-Reply-To: <Pine.LNX.4.61.0502141815320.9608@goblin.wat.veritas.com>

On Mon, Feb 14, 2005 at 06:36:43PM +0000, Hugh Dickins wrote:
> On Mon, 14 Feb 2005, Andrea Arcangeli wrote:
> > > By the way, while we're talking of remove_exclusive_swap_page:
> > > a more functional issue I sometimes wonder about, why don't we
> > > remove_exclusive_swap_page on write fault?  Keeping the swap slot
> > > is valuable if read fault, but once the page is dirtied, wouldn't
> > > it usually be better to free that slot and allocate another later?
> > 
> > Avoiding swap fragmentation is one reason to leave it allocated. So you
> > can swapin/swapout/swapin/swapout always in the same place on disk as
> > long as there's plenty of swap still available. I'm not sure how much
> > speedup this provides, but certainly it makes sense.
> 
> I rather thought it would tend to increase swap fragmentation: that
> the next time (if) this page has to be written out to swap, the disk
> has to seek back to some ancient position to write this page, when
> the rest of the cluster being written is more likely to come from a
> recently allocated block of contiguous swap pages (though if many of
> them are being rewritten rather than newly allocated, they'll all be
> all over the disk, no contiguity at all).
> 
> Of course, freeing as soon as dirty does leave a hole behind, which
> tends towards swap fragmentation: but I thought the swap allocator
> tried for contiguous clusters before it fell back on isolated pages
> (I haven't checked, and akpm has changes to swap allocation in -mm).
> 
> Hmm, I think you're thinking of the overall fragmentation of swap,
> and are correct about that; whereas I'm saying "fragmentation"
> when what I'm really concerned about is increased seeking.

Swapouts aren't the problem. The swapins with physical readahead are the
ones that benefits from the reduced overall fragmentation. Or at least
this was the case in 2.4, you're right something might be different now
that we don't follow a swapout virtual address space order anymore (but
there is probably still some localization effect during the ->nopage
faults).

  reply	other threads:[~2005-02-14 21:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-03  3:56 [RFC] Changing COW detection to be memory hotplug friendly IWAMOTO Toshihiro
2005-02-07 21:24 ` Hugh Dickins
2005-02-08 16:26   ` Hugh Dickins
2005-02-10  7:59     ` IWAMOTO Toshihiro
2005-02-10 19:05     ` Andrea Arcangeli
2005-02-10 19:16       ` Dave Hansen
2005-02-10 19:41         ` Andrea Arcangeli
2005-02-10 20:19       ` Hugh Dickins
2005-02-10 20:40         ` Andrea Arcangeli
2005-02-11  7:23           ` Hugh Dickins
2005-02-11  8:52             ` Andrea Arcangeli
2005-02-11 13:20               ` Hugh Dickins
2005-02-14 17:41                 ` Andrea Arcangeli
2005-02-14 18:36                   ` Hugh Dickins
2005-02-14 21:41                     ` Andrea Arcangeli [this message]
2005-02-15  3:17                       ` Andrew Morton
2005-02-09  9:08   ` IWAMOTO Toshihiro

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=20050214214148.GM13712@opteron.random \
    --to=andrea@suse.de \
    --cc=hugh@veritas.com \
    --cc=iwamoto@valinux.co.jp \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.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