[linux-pm] Memory allocations in .suspend became very unreliable

Maxim Levitsky maximlevitsky at gmail.com
Sat Jan 16 13:44:49 PST 2010


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



More information about the linux-pm mailing list