From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <ncunningham@clear.net.nz>
Cc: Ducrot Bruno <ducrot@poupinou.org>,
"Grover, Andrew" <andrew.grover@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI List <acpi-devel@lists.sourceforge.net>,
Swsusp <swsusp@lister.fornax.hu>
Subject: Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123
Date: Fri, 7 Feb 2003 17:00:56 +0100 [thread overview]
Message-ID: <20030207160055.GA485@elf.ucw.cz> (raw)
In-Reply-To: <1044590241.1649.41.camel@laptop-linux.cunninghams>
Hi!
> Machine 1: Celeron 933 laptop 17MB/s disk throughput, 128MB RAM
> Machine 2: Duron 700 desktop, 30MB/s disk throughput, 320MB RAM
>
> Algorithm 1: Eat as much memory as possible, save remaining in one set
> of pages
> Algorithm 2: Save memory in two pages, only eating memory if necessary.
>
> Same code base, just different parameters to /proc/sys/kernel/swsusp.
> This means that the result for algorithm 1 are exactly the same as
> Pavel's code, but should give some idea.
>
> Columns:
> (1) Machine
> (2) Algorithm
> (3) Initial # pages free
> (4) Image size written to disk
> (5) Approximate time taken (date command run on other computer at same
> time as pressing enter to start command, then when computer restarts)
>
> 1 2 3 4 5
> ---------------------------------
> 1 1 25655/30592 1562 0:07
> 1 2 26246/30592 4302 0:05
You can suspend and resume your notebook within 5 seconds? Wow!
> 1 1 1005/30592 5165 0:20
> 1 2 900/30592 30126 0:16
> 2 1 38604/79755 ? 0:49
> 2 2 39122/79755 30398 0:21
> 2 1 1113/79755 ? 0:50
> 2 2 1109/79755 82149 0:40
>
> The question marks are because the desktop machine didn't successfully
> resume using this algorithm, so stats weren't logged (probably driver
> problems).
>
> In each case, the new method is slightly faster than the old, so we don't seem to loose anything.
> Particularly interesting to me was the fact that the gain was not as
> high as we might expect when the memory was heavily used. I guess the
> amount of I/O is getting to the point where benefits from not eating
> pages are being erroded. It would be interesting to see if a machine
> with more memory readed a point where it was faster to eat the memory
> instead of write it.
Well, if all the memory is in disk-backed clean pages, it should be
faster to discard then write out...
Anyway... So your method is faster. Good. Now, how much more
complicated is it?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
next prev parent reply other threads:[~2003-02-08 16:39 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
2003-02-06 21:05 ` Ducrot Bruno
2003-02-07 3:57 ` Nigel Cunningham
2003-02-07 16:00 ` Pavel Machek [this message]
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=20030207160055.GA485@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=acpi-devel@lists.sourceforge.net \
--cc=andrew.grover@intel.com \
--cc=ducrot@poupinou.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@clear.net.nz \
--cc=swsusp@lister.fornax.hu \
/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