[lkml]   [2006]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

    On Mon, Feb 20, 2006 at 02:28:42PM +0100, Pavel Machek wrote:
    > > On Mon, Feb 20, 2006 at 06:15:46AM -0500, Lee Revell wrote:
    > > > But we have not established that the current implementation does
    > > > not work! That's a pretty strong assertion to make with zero
    > > > evidence.
    > >
    > > As I said, it did not work. Efforts to make it work just started
    > > recently, at a time when Suspend 2 already was stable and reliable
    > > to me.
    > That is not true.

    What? That Suspend 2 was stable for me that time? Yes, it definitly
    was. The same time when swsusp failed dramatically here, if there was
    progress I could not see it that time.

    > > The first try was a desaster, partly my own fault, partly because
    > > swsusp does not allow abortion (remember what I said about having a
    > > least some basic stuff in the kernel). However, I rebooted, fscked,
    > > no filesystem corruption *phew*.
    > Abortion can be done in userspace. Perhaps even as easily as ^c during
    > the suspend script.

    Actually this was on resume, while the kernel was in full control. With
    Suspend 2 I could have pressed escape (that is the ugly stuff you
    complained about), while I had to fully restart the system with sysrq+b
    with swsusp.

    > > The second try worked, with ugly messages scrolling over the
    > > console, but ok, Suspend 2 already fixes some drivers which has not
    > > yet been merged to mainline. The system resumed, which is fine.
    > Submit driver fixes, then.

    Nigel did, that is why the patch is so huge.

    > > Third try sound was gone. On the fourth try the system hanged after
    > > starting ppracer (to test GLX/DRI on my i855).
    > Submit AGP fixes, then.

    I think no such fixes are in Suspend 2, but still it works there.

    > > This is a much more recent kernel, than the ones I used with Suspend
    > > 2 for the last 1.5 problems. Problems discovered have been no issue
    > > with Suspend 2 for at least 7 or 8 months (no single crash or driver
    > > problems). This is mostly a driver issue and undoubtly can be
    > > solved, but I still do not see how this can be done when all efforts
    > > are put into just another suspend implementation (uswsusp).
    > uswsusp & swsusp & suspend2 share underlying drivers. If Nigel has
    > some fixes he had not propagated upstream... that is not *my* fault.

    Read again, I already said that this are some driver problems, and I
    think that most of them are already submitted.

    But then again, this was about work/not work, and there are still
    problems, so there is still efford needed. In this situation it is not
    good to just start over, but take the things that are already there and
    work with it.

    > > Ah, and now the part I really like, some hard numbers: swsusp takes
    > > between 26 and 30 seconds to suspend (in my four tries: 26, 30, 28,
    > > 26) and between 35 and 45 seconds to resume (35, 45, 39, 37).
    > >
    > > Suspend 2 does suspend in around 14-16 seconds, and resume in 18 to
    > > 21.
    > >
    > > That is factor 2!
    > Does that include time to boot resume kernel? It will not be that
    > dramatic with that time included, and it is only fair to include it.

    Actually it is, yes. This time is dramatic and includes the full time I
    see from a user point of view.

    Time for suspend was measured from the time I started hibernate (Suspend
    2)/echoed disk into /sys/power/state (swsusp) until the moment the
    notebook powered down.

    Time for resume was measured from the time I pressed enter in grub and
    the system was back will full X and drivers and ready to work.

    I think this is a fair time comparision, and it is a dramatic factor of
    2. (BTW: the time from powering on the notebook until the grub-menu
    comes up takes 3 seconds, so feel free to add this. It would not make a
    huge difference.)

    However, this test was made with very empty caches, I suspect after some
    more work when the caches get filled, this will change even more
    dramatically, thanks to LZF compression (which might be in uswsusp, but
    is not in swsusp).

    > Anyway uswsusp solves that issue.

    Maybe it will, but when?

    I looks like that we are at the same point we started from: swsusp had a
    lot of problems in the past and is still not working so great and also
    very slow. Suspend 2 has proved to be stable and reliable for nearly a
    year. Work on uswsusp has just started and needs a lot of time to become

    And here is my point again: take the easiest way to make hibernation
    working fast, and when that is done start to work on any new

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-20 14:54    [W:0.026 / U:13.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site