[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Suspending cached pages


  • To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
  • From: Jan Rychter <jan@xxxxxxxxxxx>
  • Date: Fri, 19 Mar 2004 00:25:37 -0800
  • Cancel-lock: sha1:LGFYZvJAWJqp9IKjTA8cUjd5hp0=
  • Delivery-date: Mon, 22 Mar 2004 07:42:22 +0000
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>

[...]
 >> I seem to recall that before swsusp actually starts its suspension
 >> of memory to disk scripts prepare the machine state and cache pages
 >> are not written out.  This means that full performance isn't
 >> returned immediately after resumption, but presumably it's just as
 >> fast to re-read the cache back from files on disk rather than pages
 >> from a suspend file, and it minimises machine state.

>>>>> "Ian" == Ian Pratt <Ian.Pratt@xxxxxxxxxxxx> writes:
 Ian> I would imagine that restoring the buffer cache in one go is
 Ian> typically faster than taking a whole string of faults, but it
 Ian> depends on how well the buffer cache is working for the
 Ian> application.

It is definitely faster on a laptop. Swsusp used to discard (actually
"eat") cache, but it doesn't do that anymore. It is much better to
preserve it across suspend/resume cycles, otherwise you end up with a
flurry of disk activity right after you resume.

On a laptop it also helps, because if you preserve it, you allow the
disk to spin down. If you discard it every time, there is a much bigger
chance that the data you need has to be read from the hard drive.

For those who care about image size and suspend speed, swsusp2 now
includes LZF compression. I get average savings of about 40% and
increased suspend speed.

--J.

Attachment: pgp3gZ1DHq9By.pgp
Description: PGP signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.