lkml.org 
[lkml]   [2007]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
    Date
    Am Mittwoch 25 April 2007 schrieb Pavel Machek:
    > Hi!
    >
    > > This is why there's a lot to be said for
    > >
    > > echo mem > /sys/power/state
    > >
    > > and being able to follow the path through _one_ object (the kernel)
    > > over trying to figure out the interaction between many different
    > > parts with different versions.
    >
    > The 'promise' is 'if you can get echo disk > /sys/power/state working,
    > uswsusp will work. too'. IOW it should be ok to debug the in-kernel
    > parts, only.

    Hello Nigel, Pavel, Rafael and everyone else who is involved,

    I would like to ask what come out of the suspend2 merge discussion. Nigel
    just told that suspend2 likely won't be merged anytime soon and thats its
    business as usual:

    ---------------------------------------------------------------------
    It's pretty much business as usual. Linus doesn't want another
    implementation merged, and he wants the three of us (Pavel, Rafael and
    myself) to agree on a way forward. He also believes that we're
    approaching things from the wrong direction at the moment. Funnily
    enough, this is the one area on which we do all agree.
    ---------------------------------------------------------------------
    http://lists.suspend2.net/lurker/message/20070510.021641.fe306add.en.html


    Has there been any further discussion and preferably agreement on the way
    to go forward?

    Although you Linus, as I read from different mails only use suspend to
    RAM, there are many users out there who use suspend to disk daily.

    I used in kernel software suspend initially and it worked quite nice with
    starting from 2.6.10 or 2.6.11 where suspend2 didn't work for me before
    2.6.14 with the hibernate script. But from then on suspend2 worked better
    than in kernel software suspend for me and colleagues on:

    - ThinkPad T23
    - ThinkPad T42
    - Possibly some other ThinkPads
    - as well various Dell workstations we have at work

    It was faster and more reliable, yielding uptimes up to 40 days on my
    workstation recently (with 2.6.17.7 still). And even that uptime was only
    ended by booting a newly build kernel (2.6.21 with sws 2.2.9.13). For me
    in the role of a user actually this is a really satisfying solution!

    I tried userspace software suspend from time to time but then just was fed
    up with it, cause I could not get it to work within any sensible amount
    of time - even with some bog standard Debian kernel, I think it was some
    2.6.18 one. Maybe I am dumb, but so be it, it should not be that
    complicated to get it to work. Recently I didn't even bother to try
    anymore. Well and I read in the suspend2 merge discussion that even in
    kernel suspend does not work reliably anymore.

    As long I cannot be convinced that the vanilla kernel contains a suspend
    to disk solution that works as good as suspend2 I will patch suspend2
    into all of the desktop kernels I build.

    Thats quite bad IMHO for exactly the same reason than having drivers
    maintained out of the kernel. For the same reason I think swap prefetch
    should go in as soon as possible. It will never have the adoption and
    care taking of an in-kernel-tree solution.

    I am convinced that a working suspend to RAM just is not enough - well it
    wasn't working correctly last time I checked. But I even don't bother
    about suspend to RAM anymore. I can wait those additional seconds for
    suspend to disk and it allows me to drive my laptops without batteries
    most of the time and have workstations switched off completely so that
    they do not consume standby power.

    So please, pretty please consider working together on a reliable, fast,
    stable, easy to use and configurable in-kernel-tree snapshot solution!
    Actually I as a user I couldn't care less about the implementation
    details, but as someone who is interested in kernel technologies I like
    it to be a clean and well designed solution, too. ;-)

    Maybe when the Linux Foundation organizes a meeting for Nigel, Pavel,
    Rafael and other kernel developers interested in creating such a solution
    it will help. To me it seems such a concentrated meeting in a good
    atmosphere could be more effective than endless mailing list discussions
    not leading to a clear result. When its not easy for the involved people
    to work together maybe a casual bystander who understands enough of
    kernel details should moderate the meeting and help finding an agreement.

    It would just be such a pity to miss the chance to have a nicely working
    snapshot solution in the Linux kernel, that may even be interesting for
    virtualization (you could store a backup of a machine state permanently
    or even more of them - if not already available through other
    technologies like well suspend2 with filewriter for example).

    Regards,
    --
    Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
    GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2007-05-26 19:41    [W:0.059 / U:0.100 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site