Re: Remove pmdisk from kernel

From: Nigel Cunningham
Date: Mon Mar 15 2004 - 17:26:29 EST


Hi.

On Tue, 2004-03-16 at 10:53, Andrew Morton wrote:
> Nigel Cunningham <ncunningham@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, 2004-03-16 at 10:21, Andrew Morton wrote:
> > > Pavel Machek <pavel@xxxxxx> wrote:
> > > >
> > > > I believe that you don't want swsusp2 in 2.6. It has hooks all over
> > > > the place:
> > > > ...
> > > > 109 files changed, 3254 insertions(+), 624 deletions(-)
> > >
> > > Ahem. Agreed.
> >
> > Most of those changes are hooks to make the freezer for more reliable.
> > That part of the functionality could be isolated from the bulk of
> > suspend2. Would that make you happy?
>
> It would make us happier. Even happier would be a series of small, well
> explained patches which bring swsusp into a final shape upon which more
> than one developer actually agrees.

I'd love to do that too. Unfortunately I'm really busy with my new job,
so things have progressed far more slowly than I'd have liked. I'm also
not sure how to deal with some of the changes that just about completely
rewrite sections.

> These wholesale replacements and deletions are an indication that something
> has gone wrong with the development process here.

I spent a long time trying to get the freezer working reliably with the
kind of implementation Pavel uses. The problem I kept running into time
and again was that you can't know dependancies between processes when it
comes to signalling them; process A might happily be frozen, but then
process B can't be frozen becaue it is waiting on something process A
has (eg ls/nfsd). By tracking which processes are in those
'can't-be-frozen-here' sections, I have managed to make the freezer far
more reliable, even under high load. Michael Frank has done some extreme
stress testing and can verify this.

Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.

-
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/