Re: Freezer Patches.

[Nigel Cunningham]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/