Re: Memory allocations in .suspend became very unreliable

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Sat, 2010-01-16 at 01:57 +0100, Rafael J. Wysocki wrote: 
> On Saturday 16 January 2010, Maxim Levitsky wrote:
> > On Fri, 2010-01-15 at 23:03 +0100, Rafael J. Wysocki wrote: 
> > > On Friday 15 January 2010, Maxim Levitsky wrote:
> > > > Hi,
> > > 
> > > Hi,
> > > 
> > > > I know that this is very controversial, because here I want to describe
> > > > a problem in a proprietary driver that happens now in 2.6.33-rc3
> > > > I am taking about nvidia driver.
> > > > 
> > > > Some time ago I did very long hibernate test and found no errors after
> > > > more that 200 cycles.
> > > > 
> > > > Now I update to 2.6.33 and notice that system will hand when nvidia
> > > > driver allocates memory is their .suspend functions. 
> > > 
> > > They shouldn't do that, there's no guarantee that's going to work at all.
> > > 
> > > > This could fail in 2.6.32 if I would run many memory hungry
> > > > applications, but now this happens with most of memory free.
> > > 
> > > This sounds a little strange.  What's the requested size of the image?
> > Don't know, but system has to be very tight on memory.
> 
> Can you send full dmesg, please?

I deleted it, but for this case I think that hang was somewhere else.
This task was hand on doing forking, which probably happened even before
the freezer.

Anyway, the problem is clear. Now __get_free_pages blocks more often,
and can block in .suspend even if there is plenty of memory free.

I now patched nvidia to use GFP_ATOMIC _always_, and problem disappear.
It isn't such great solution when memory is tight though....

This is going to hit hard all nvidia users...

Best regards,
Maxim Levitsky