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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
