[lkml]   [2009]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.


    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 :
    - 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 17 days, 21:47:04 | Linux
    3 17 days, 12:38:36 | Linux
    4 15 days, 14:39:26 | Linux
    5 15 days, 13:58:12 | Linux
    6 12 days, 21:54:18 | Linux
    7 10 days, 22:02:14 | Linux
    8 10 days, 08:04:52 | Linux
    9 8 days, 00:34:34 | Linux
    10 7 days, 12:56:54 | Linux

    (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

    Martin 'Helios' Steigerwald -
    GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2009-05-16 21:09    [W:4.089 / U:0.608 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site