RE: [PATCH] s4bios for 2.5.59 + apci-20030123

RE: [PATCH] s4bios for 2.5.59 + apci-20030123

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup@poupinou.org] 
> This patch is for s4bios support in 2.5.59 with acpi-20030123.
> 
> This is the 'minimal' requirement.  Some devices (especially the
> IDE part) are not well resumed.  Handle with care..
> 
> Note also that the resuming part (I mean IDE) was more stable
> with an equivalent patch when I tested with 2.5.54 (grumble 
> grumble)...
> 
> I think also that it is a 'good' checker for devices power management
> in general...

I'd really rather just have S4OS (aka swsusp) in 2.5 patches -- if the
OS can do S4 on its own, that is really preferable to S4bios.

Regards -- Andy

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

[Pavel Machek]

Hi!

> > This patch is for s4bios support in 2.5.59 with acpi-20030123.
> > 
> > This is the 'minimal' requirement.  Some devices (especially the
> > IDE part) are not well resumed.  Handle with care..
> > 
> > Note also that the resuming part (I mean IDE) was more stable
> > with an equivalent patch when I tested with 2.5.54 (grumble 
> > grumble)...
> > 
> > I think also that it is a 'good' checker for devices power management
> > in general...
> 
> I'd really rather just have S4OS (aka swsusp) in 2.5 patches -- if the
> OS can do S4 on its own, that is really preferable to S4bios.

Well, we already have S4OS, and having S4OS does not mean we can't
have S4bios.

Some people apparently want slower suspend/resume but have all caches
intact when resumed. Thats not easy for swsusp but they can have that
with S4bios. And S4bios is usefull for testing device support; it
seems to behave slightly differently to S3 meaning better testing.

If you already have hibernation partition from factory, which you are
using anyway for w98, S4bios is easier to use and more foolproof
(i.e. you can't boot into wrong kernel which does not resume but does
fsck instead).

								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

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

[Ducrot Bruno]

On Tue, Feb 04, 2003 at 11:10:04PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > This patch is for s4bios support in 2.5.59 with acpi-20030123.
> > > 
> > > This is the 'minimal' requirement.  Some devices (especially the
> > > IDE part) are not well resumed.  Handle with care..
> > > 
> > > Note also that the resuming part (I mean IDE) was more stable
> > > with an equivalent patch when I tested with 2.5.54 (grumble 
> > > grumble)...
> > > 
> > > I think also that it is a 'good' checker for devices power management
> > > in general...
> > 
> > I'd really rather just have S4OS (aka swsusp) in 2.5 patches -- if the
> > OS can do S4 on its own, that is really preferable to S4bios.
> 
> Well, we already have S4OS, and having S4OS does not mean we can't
> have S4bios.
> 
> Some people apparently want slower suspend/resume but have all caches
> intact when resumed. Thats not easy for swsusp but they can have that
> with S4bios. And S4bios is usefull for testing device support; it
> seems to behave slightly differently to S3 meaning better testing.
> 

Yep, correct.  The problem is that now I have more trouble with s4bios
in general with 2.5.  That worked more reliability with 'older' 2.5 series.
Really don't know why.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

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

[Nigel Cunningham]

On Wed, 2003-02-05 at 11:10, Pavel Machek wrote:
> Some people apparently want slower suspend/resume but have all caches
> intact when resumed. Thats not easy for swsusp but they can have that
> with S4bios. And S4bios is usefull for testing device support; it
> seems to behave slightly differently to S3 meaning better testing.

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.

> 
> If you already have hibernation partition from factory, which you are
> using anyway for w98, S4bios is easier to use and more foolproof
> (i.e. you can't boot into wrong kernel which does not resume but does
> fsck instead).

It doesn't really matter what kernel is loaded when we start a resume
anyway, does it? Could they not be different versions because one is
going to replace the other anyway?

Regards,

Nigel

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

[Ducrot Bruno]

On Thu, Feb 06, 2003 at 09:41:44AM +1300, Nigel Cunningham wrote:
> On Wed, 2003-02-05 at 11:10, Pavel Machek wrote:
> > Some people apparently want slower suspend/resume but have all caches
> > intact when resumed. Thats not easy for swsusp but they can have that
> > with S4bios. And S4bios is usefull for testing device support; it
> > seems to behave slightly differently to S3 meaning better testing.
> 
> 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.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

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

[Pavel Machek]

Hi!

> > Some people apparently want slower suspend/resume but have all caches
> > intact when resumed. Thats not easy for swsusp but they can have that
> > with S4bios. And S4bios is usefull for testing device support; it
> > seems to behave slightly differently to S3 meaning better testing.
> 
> 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.
> 
> > If you already have hibernation partition from factory, which you are
> > using anyway for w98, S4bios is easier to use and more foolproof
> > (i.e. you can't boot into wrong kernel which does not resume but does
> > fsck instead).
> 
> It doesn't really matter what kernel is loaded when we start a resume
> anyway, does it? Could they not be different versions because one is
> going to replace the other anyway?

No, no. It has to be exactly the same kernel, otherwise you get a nice
crash (if you are lucky) and ugly data corruption (when you are not);
there's check to prevent that and panic, however.

That's why I call S4bios more foolproof.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

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

[Nigel Cunningham]

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

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

[Nigel Cunningham]

On Fri, 2003-02-07 at 04:37, Pavel Machek wrote:

> No, no. It has to be exactly the same kernel, otherwise you get a nice
> crash (if you are lucky) and ugly data corruption (when you are not);
> there's check to prevent that and panic, however.
> 
> That's why I call S4bios more foolproof.

Oh of course; I'm with you. If you're running a different kernel, you
must have had an entirely different context when you suspended. Humble
apologies; I was only thinking about whether the image would
successfully load, not the difference in contents.

Regards,

Nigel

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

[Ducrot Bruno]

On Fri, Feb 07, 2003 at 08:41:27AM +1300, Nigel Cunningham wrote:
> 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

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

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

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

[Nigel Cunningham]

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

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

[Pavel Machek]

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?

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

[Nigel Cunningham]

Hi

On Sat, 2003-02-08 at 05:00, Pavel Machek wrote: 
> > 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!

As requested, these were just the times for suspending.

> Well, if all the memory is in disk-backed clean pages, it should be
> faster to discard then write out...

Yes, I would think so too. Perhaps the differences would probably
disappear if I made the algorithm more like your original (ie simplifed
eat_memory back to the original), but I do remember lots of disk
activity when using the original code as well - perhaps the cause might
be worth further investigation? (Not that I'm volunteering)

> Anyway... So your method is faster. Good. Now, how much more
> complicated is it?

As I've said above, I'm not sure it is right to say it is faster - I
didn't compare your current method with the new one, but rather mine
with parameters making the algorithm as close to yours as possible. My
point was more that if the new method is slower, its not significantly
slower.

Nevertheless, you do have a good point - it is more complicated. But I
think it's worth it and its not a lot more complicated. People who are
using the new method at the moment appreciate the changes. Don't think
for a moment that I don't value your work, Pavel. I couldn't have done
any of my additions without it and consider mine tweaking. This has
simply been a quest to get a more responsive system on resume.

Regards,

Nigel