Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Nigel Cunningham <ncunningham-oKK1aGe2n869koe0gwxAeg@public.gmane.org>]

On Fri, 2003-02-07 at 10:05, Ducrot Bruno wrote:
> On Fri, Feb 07, 2003 at 08:41:27AM +1300, Nigel Cunningham wrote:
> > 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
> 
> Ah ok.  I understand now.  S4bios is completely different from swsusp.
> It's just as if we were comparing APM suspend-to-disk and swsusp (and no, S4bios
> is *not* APM suspend-to-disk either).

FWIW, here are the results of some tests, timing
2.4.21-pre3+acpi20030125+swsusp-beta18:

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
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.

Hope this is helpful.

Nigel