Re: swsusp: fix error handling in "not enough swap space"

[Pavel Machek]

Hi!

> >>>Quite easy to say. I don't really understeand all changes that 've been 
> >>>done over mm between 2.6.6-rc2-bk2 and 2.6.5.
> >>>     
> >>>
> >
> >I know its easy to say ;-).
> > 
> >
> I am looking forward to see someone explaining me what has changed there 
> acctually. This time, I am sure, obviously, kernel is counting free 
> pages wrong. At least it does it incorrectly when it's about to
> 'hibernate'.

I do not know what went wrong there. If I did, I'd just fix it.

*But* if your test program doing malloc() in loop broke, you probably
want to post test program to l-k, get akpm's attetion, and make
someone fix it.

> >If you do something stupid, its okay that kernel is not able to
> >suspend. F3 on /dev/kmem counts as "something stupid". If you find out
> >something normal user (not root) can do... we are more likely to fix
> >that.
> >
> >I'd say that /dev/kmem issue is not worth fixing. NFS issue may be
> >worth fixing, but I do not use NFS that much. Any other problems?
> > 
> >
> Those were just ways of reproducing problem. I know they are not very 
> likely to be the case in real life, but simmilar lock up may occur 
> somewhere else.

Similar lock probably is there in few more places. Approach is "fix
them one by one". Not the nicest one, but...

So yes, I'm aware there are probably more cases like that; I just
don't know effective way to find them all.

> Well, maybe all beside nfs case. It just happends sometimes that network 
> is over congested, just the real life.

freeze_processes tries for 5 seconds. That should be enough to handle
common network congestion.
								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc
-
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/