linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@clear.net.nz>
To: Ducrot Bruno <ducrot@poupinou.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	"Grover, Andrew" <andrew.grover@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI List <acpi-devel@lists.sourceforge.net>
Subject: Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123
Date: Fri, 07 Feb 2003 08:41:27 +1300	[thread overview]
Message-ID: <1044560486.1700.13.camel@laptop-linux.cunninghams> (raw)
In-Reply-To: <20030206101645.GO1205@poup.poupinou.org>

On Thu, 2003-02-06 at 23:16, Ducrot Bruno wrote:
> On Thu, Feb 06, 2003 at 09:41:44AM +1300, Nigel Cunningham wrote:
> > Whether its slower depends on the hardware; on my 128MB Celeron 933
> > laptop (17MB/s HDD), I can write an image of about 120MB, reboot and get
> > back up and running in around a minute and a half. That's about the same
> > as far as I remember, but has (as you say) the advantage of not still
> > having to get things swapped back in.
> 
> The problem is the speed of the suspending process, not the whole suspend/resume
> sequence,  especially in case of emergency suspending due to thermal condition,
> etc.

Sorry. Perhaps I should have been clearer. I haven't spent a lot of time
doing timings, but there doesn't seem to be any significant difference.
In both versions, the amount of time varies with the amount of memory in
use. When not much memory is in use, both are fast because there's not
much to do anyway. When lots of memory is in use, both are slower. The
old version is slower because it eats as much memory as it can, and this
can take significant amounts of time, then makes a copy of every page
remaining, before saving those pages to disk. The new version doesn't
usually eat any memory, and when it does, not much is eaten. It then
saves all the pages that aren't needed for the suspend process directly
to disk; always more than half, sometimes all but about a few thousand
pages. It then uses this memory for the copy & save of remaining pages.
Thus, in one version, the major portion of time is taken in eating
memory (and post resume, loading pages back in) whereas in the 'new'
version, the time taken is almost purely a function of IO speed.

If you like, I'll do some timings on my 320MB desktop machine and post
them later in the day.

Regards,

Nigel


  reply	other threads:[~2003-02-06 19:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-04  1:25 [PATCH] s4bios for 2.5.59 + apci-20030123 Grover, Andrew
2003-02-04 22:10 ` Pavel Machek
2003-02-05 20:05   ` [ACPI] " Ducrot Bruno
2003-02-05 20:41   ` Nigel Cunningham
2003-02-06 10:16     ` Ducrot Bruno
2003-02-06 19:41       ` Nigel Cunningham [this message]
2003-02-06 21:05         ` Ducrot Bruno
2003-02-07  3:57           ` Nigel Cunningham
2003-02-07 16:00             ` Pavel Machek
2003-02-09 19:42               ` Nigel Cunningham
2003-02-06 15:37     ` Pavel Machek
2003-02-06 19:44       ` Nigel Cunningham

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=1044560486.1700.13.camel@laptop-linux.cunninghams \
    --to=ncunningham@clear.net.nz \
    --cc=acpi-devel@lists.sourceforge.net \
    --cc=andrew.grover@intel.com \
    --cc=ducrot@poupinou.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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;
as well as URLs for NNTP newsgroup(s).