public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Jeff Garzik <garzik@gtf.org>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch 10/16] give swapper_space a set_page_dirty a_op
Date: Sat, 01 Jun 2002 15:38:22 -0700	[thread overview]
Message-ID: <3CF94CDE.40A55D69@zip.com.au> (raw)
In-Reply-To: <3CF88908.179B10BF@zip.com.au> <20020601161424.A4535@gtf.org>

Jeff Garzik wrote:
> 
> On Sat, Jun 01, 2002 at 01:42:48AM -0700, Andrew Morton wrote:
> >
> >
> > Give swapper_space a ->set_page_dirty() address_space_operation.
> 
> Remember that we don't need swapper_space at all?

swapper_space makes some sense...

> All the underlying inodes have their own address spaces, and the
> SWP_ENTRY tells us what we need to know, to find the underlying address
> spaces.
> 
> swapper_space is just a master address space that overlays the
> underlying multiple address spaces.  We can just look directly at the
> underlying ones...

Nope.  swapper_space is a single, standalone mapping which implements
its own (striped) I/O direct to block devices.  To locate the blockdev
it goes:

	swap_files[type]->f_dentry->d_inode->i_bdev

Swap never talks to d_inode->i_mapping.  If someone else is accessing that
device then their view of the device will be via bdinode->i_mapping and
is not coherent with swapper_space.

swapper_space can get at the underlying device via its own block
mapping function or via a swapfile's bmap() function.   But either
way, it goes direct to the blockdev via brw_page().

All those inodes and file*'s are just a way for swap to get directly
at the blockdev, which is a good thing for swap to be doing.

Yes, possibly we could stripe swap at the address_space level, and
switch anon pages in and out of the individual blockdev mappings.

But that's more complex, and means that swap would have to be able to
deal with external agents coming in and randomly locking its buffers
and pages (it'll oops at present if that happens, but it can't because
nobody can get at swapper_space's pages and buffers).

Plus the blockdev mapping uses PAGE_CACHE_SIZE pages, and swap
uses PAGE_SIZE pages.   I do think the design is OK as-is.

-

      reply	other threads:[~2002-06-01 22:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-01  8:42 [patch 10/16] give swapper_space a set_page_dirty a_op Andrew Morton
2002-06-01 20:14 ` Jeff Garzik
2002-06-01 22:38   ` Andrew Morton [this message]

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=3CF94CDE.40A55D69@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=garzik@gtf.org \
    --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