Re: Freezer Patches.

From: Nigel Cunningham (ncunningham_at_cyclades.com)
Date: 06/02/05

  • Next message: Nigel Cunningham: "Re: Freezer Patches." 
    To: Pavel Machek <pavel@ucw.cz>
Date:	Thu, 02 Jun 2005 11:45:54 +1000

    Hi.

    On Thu, 2005-06-02 at 09:02, Pavel Machek wrote:
    > On Čt 02-06-05 08:45:33, Benjamin Herrenschmidt wrote:
    > > On Thu, 2005-06-02 at 00:31 +0200, Pavel Machek wrote:
    > > > Hi!
    > > >
    > > > (Well, it is just after midnight here :-).
    > > >
    > > > > > > Here are the freezer patches. They were prepared against rc3, but I
    > > > > > > think they still apply fine against rc5. (Ben, these are the same ones I
    > > > > > > sent you the other day).
    > > > > >
    > > > > > 304 seems ugly and completely useless for mainline
    > > > >
    > > > > That's because you don't understand what it's doing.
    > > > >
    > > > > The new refrigerator implementation works like this:
    > > > >
    > > > > Userspace processes that begin a sys_*sync gain the process flag
    > > > > PF_SYNCTHREAD for the duration of their syscall.
    > > >
    > > > swsusp1 should not need any special casing of sync, right? We can
    > > > simply do sys_sync(), then freeze, or something like that. We could
    > > > even remove sys_sync() completely; it is not needed for correctness.

    Wrong. I guess you're only trying it on a machine that isn't actually
    doing anything :). I've forgotten whether it was this freezer
    implementation or the last, but we've been testing freezing processes
    when the load average exceeds 100. If you have a thread that is syncing
    and another that's submitting I/O continually (think dd, for example),
    you want this.

    > > It's still quite nice to have ... I put it in my pre-freeze callback in
    > > fact for both STR and STD :) We really want it for STD but I think it
    > > doesn't work properly after freeze.
    >
    > I agree that sync() is nice to have, but I'm not going to slow down
    > fork/exit for it. And besides, sys_sync() just before suspend works
    > just fine.

    Again, try it under load... and stop talking about fork and exit like
    they're real hot paths. (Unless you regularly submit your machines to
    fork bombs :)).

    Regards,

    Nigel

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Nigel Cunningham: "Re: Freezer Patches."

    Relevant Pages

    • Re: Remove pmdisk from kernel
      ... >> Most of those changes are hooks to make the freezer for more reliable. ... process B can't be frozen becaue it is waiting on something process A ... Nigel Cunningham ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Remove pmdisk from kernel
      ... >> Most of those changes are hooks to make the freezer for more reliable. ... signal the NFSd threads before the ls thread, ... The best way to test the reliability of the current freezer ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Freezer Patches.
      ... I've forgotten whether it was this freezer ... If you have a thread that is syncing ... work around it in refrigerator. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Dealing with swsusp vs. pmdisk
      ... freezer should not be needed for s-to-ram. ... for drivers. ... When do you have a heart between your knees? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)