public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: linux-kernel@vger.kernel.org, xen-devel@lists.sf.net
Subject: Re: [XEN] using shmfs for swapspace
Date: Mon, 3 Jan 2005 20:53:18 +0000	[thread overview]
Message-ID: <20050103205318.GD6631@lkcl.net> (raw)
In-Reply-To: <20050103183133.GA19081@samarkand.rivenstone.net>

On Mon, Jan 03, 2005 at 01:31:34PM -0500, Joseph Fannin wrote:
> On Sun, Jan 02, 2005 at 04:26:52PM +0000, Luke Kenneth Casson Leighton wrote:
> [...] 
> > this is presumed to be infinitely better than forcing the swapspace to
> > be always on disk, especially with the guests only being allocated
> > 32mbyte of physical RAM.
> 
>     I'd be interested in knowing how a tmpfs that's gone far into swap
> performs compared to a more normal on-disk fs.  I don't know if anyone
> has ever looked into it.  Is it comparable, or is tmpfs's ability to
> swap more a last-resort escape hatch?
> 
>     This is the part where I would add something valuable to this
> conversation, if I were going to do that. (But no.)

 :)

 okay.
 
 some kind person from ibm pointed out that of course if you use a
 file-based swap file (in xen terminology,
 disk=['file:/xen/guest1-swapfile,/dev/sda2,rw'] which means "publish
 guest1-swapfile on the DOM0 VM as /dev/sda2 hard drive on the
 guest1 VM) then you of course end up using the linux filesystem cache
 on DOM0 which is of course RAM-based.

 so this tends to suggest a strategy where you allocate as
 much memory as you can afford to the DOM0 VM, and as little
 as you can afford to the guests, and make the guest swap
 files bigger to compensate.

 ... and i thought it was going to need some wacky wacko non-sharing
 shared-memory virtual-memory pseudo-tmpfs block-based filesystem
 driver.  dang.

 l.


  reply	other threads:[~2005-01-03 20:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-02 16:26 [XEN] using shmfs for swapspace Luke Kenneth Casson Leighton
2005-01-03 18:31 ` Joseph Fannin
2005-01-03 20:53   ` Luke Kenneth Casson Leighton [this message]
2005-01-03 21:06     ` Alan Cox
2005-01-04  3:04       ` [Xen-devel] " Mark Williamson
2005-01-04 14:05         ` Rik van Riel
2005-01-06 11:38           ` Luke Kenneth Casson Leighton
2005-01-05  0:11         ` Arnd Bergmann
2005-01-21 21:37           ` Rik van Riel
2005-01-26 20:56             ` Mark Williamson
2005-01-27 10:33               ` Nuutti Kotivuori
2005-01-03 21:07     ` Adam Heath
2005-01-04  9:30       ` Luke Kenneth Casson Leighton
2005-01-04 14:06         ` Rik van Riel

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=20050103205318.GD6631@lkcl.net \
    --to=lkcl@lkcl.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.sf.net \
    /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