Message-Id: <200905162107.58677.Martin@lichtvoll.de>
Date:	Sat, 16 May 2009 21:07:51 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	tuxonice-devel@...ts.tuxonice.net
Cc:	Nigel Cunningham <nigel@...onice.net>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [TuxOnIce-devel] [RFC] TuxOnIce

Am Mittwoch 06 Mai 2009 schrieb Nigel Cunningham:
> I'd like to submit TuxOnIce for review, with a view to seeking to get
> it merged, perhaps in 2.6.31 or .32 (depending upon what needs work
> before it can be merged) and the willingness of those who matter.
>
> To briefly summarise the advantages to merging TuxOnIce:

As a user I support this.

Why?

Cause everytime I tried TuxOnIce just worked while I had various problems 
whenever I tried out any in-kernel snapshot stuff, be it hard-wired or 
userspace supported. Actually I never could have been bothered to try out 
to fix any issues with these while I just had a working solution and 
thats TuxOnIce. Might have been that issues could have been fixed - but 
exactly why should I care when I have something that just works? Honestly 
I can't even be bothered to remember those issues in detail. It was 
crashes, hangs and on the last occurence of testing mostly slowness while 
it basically worked mostly. Release versions of TuxOnIce didn't fail for 
me as long as I can remember.

My case for TuxOnIce?

shambhala:~> cat /sys/power/tuxonice/debug_info
TuxOnIce debugging info:
- TuxOnIce core  : 3.0.1
- Kernel Version : 2.6.29.2-tp42-toi-3.0.1
- Compiler vers. : 4.3
- Attempt number : 39
- Parameters     : 0 667656 0 1 700 5
- Overall expected compression percentage: 30.
- Checksum method is 'md4'.
  0 pages resaved in atomic copy.
- Compressor is 'lzo'.
  Compressed 528949248 bytes into 223456685 (57 percent compression).
- Max outstanding reads 570. Max writes 132.
  Memory_needed: 1024 x (4096 + 216 + 72) = 4489216 bytes.
  Free mem throttle point reached 0.
- SwapAllocator active.
  Swap available for image: 661830 pages.
- FileAllocator inactive.
- I/O speed: Write 41 MB/s, Read 35 MB/s.
- Extra pages    : 18 used/500.
- Result         : Succeeded.

39 attempts and counting.

I have seen uptimes of up to almost 70 days and this one has only been 
interrupted by user error - shutting down instead of triggering snapshot.

shambhala:~> uprecords | head -12 | cut -b1-56
     #               Uptime | System
----------------------------+---------------------------
     1    31 days, 01:07:24 | Linux 2.6.26.5-tp42-toi-
->   2    17 days, 21:47:04 | Linux 2.6.29.2-tp42-toi-
     3    17 days, 12:38:36 | Linux 2.6.28.8-tp42-toi-
     4    15 days, 14:39:26 | Linux 2.6.28.4-tp42-toi-
     5    15 days, 13:58:12 | Linux 2.6.27.7-tp42-toi-
     6    12 days, 21:54:18 | Linux 2.6.26.5-tp42-toi-
     7    10 days, 22:02:14 | Linux 2.6.28.7-tp42-toi-
     8    10 days, 08:04:52 | Linux 2.6.26.2-tp42-toi-
     9     8 days, 00:34:34 | Linux 2.6.28.7-tp42-toi-
    10     7 days, 12:56:54 | Linux 2.6.28.8-tp42-toi-

(uprecords cuts kernel version, so concrete TuxOnIce versions are missing. 
Including low uptimes with 2.6.28 due to hard crashes during preparing 
hibernation when the switch from X11 to console frame buffer was about to 
come - which luckily appear to have gone with 2.6.29. And from time to 
time I can be bothered to upgrade the kernel as well.)

And the speed - which even got higher after the switch from LZF to 
in-kernel LZO:

shambhala:~> zgrep "I/O speed" /var/log/syslog | sed 's/localhost //' | 
tail -10
May 10 18:15:09 kernel: - I/O speed: Write 49 MB/s, Read 48 MB/s.
May 11 09:37:31 kernel: - I/O speed: Write 49 MB/s, Read 45 MB/s.
May 12 08:22:55 kernel: - I/O speed: Write 46 MB/s, Read 45 MB/s.
May 12 19:40:25 kernel: - I/O speed: Write 45 MB/s, Read 42 MB/s.
May 13 09:03:34 kernel: - I/O speed: Write 44 MB/s, Read 35 MB/s.
May 13 19:21:31 kernel: - I/O speed: Write 50 MB/s, Read 39 MB/s.
May 14 08:51:45 kernel: - I/O speed: Write 46 MB/s, Read 38 MB/s.
May 15 08:52:53 kernel: - I/O speed: Write 46 MB/s, Read 40 MB/s.
May 16 12:56:10 kernel: - I/O speed: Write 53 MB/s, Read 54 MB/s.
May 16 19:08:55 kernel: - I/O speed: Write 41 MB/s, Read 35 MB/s.

Thats on ThinkPad T42 with 160 GB Hitachi IDE drive.

My conclusion: TuxOnIce is awesome.

I do not add anything more to the general discussion. I am fine with 
TuxOnIce replacing in-kernel snapshot implementation. I am also fine with 
TuxOnIce serving as inspiration to make in-kernel snapshot better. But I 
for my take can't be bothered to waste my precious time to try out 
in-kernel stuff again unless I can be convinced that it might have a 
competitive reliability, speed and feature set. In the role of an user I 
can be very lazy. TuxOnIce in kernel would convince me, thats for sure. 

I am pretty puzzled that apparently apart from Sam Ravnborg no kernel 
developer made any public review of concrete patches.

I think the effort of Nigel deserves a bit more than general comments and 
the usual userspace versus in kernel discussion. At least some hints for 
Nigel for what he should change in general in order to improve the 
likelihood of a review. In the moment it appears to me that it has been 
rejected without even looking at it.

So what are the *concrete* issues with the patchset Nigel posted?

I respect that kernel developers have the right to be lazy as well ;). And 
I am free to compile my own kernels for as long as I see fit with 
TuxOnIce being probably my only reason to do so.

But I ask for at least some concrete feedback on the concrete patchset 
Nigel posted, instructions for Nigel on what to change / do differently - 
apart from that general and repetitive discussion. Does the patchset need 
to be smaller? Should patches be split or joined? Should comments be 
improved? Should the patchset be structured differently?

And when replacing in kernel snapshot implementation by TuxOnIce is 
completely out of question - even without looking at the concrete 
patchset - I ask for concrete hints on alternative approaches Nigel could 
follow.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists