Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: [linux-pm] Memory allocations in .suspend became very unreliable) | Date | Tue, 19 Jan 2010 10:19:29 +0900 (JST) |
| |
Hi
> > If suspend need lots memory, we need to make free memory before starting IO > > suspending, I think. > > Suspend as such doesn't need a lot of memory, except for some drivers doing > things they shouldn't do. > > However, there are a few problems that need to be addressed in general. > > First, we can't really guarantee that there's a lot of free memory available > during suspend and some memory allocations are done indirectly, using > GFP_KERNEL (for example, when new kernel threads are started). If one of > these is done during suspend and it happens to cause the mm subsystem to > start I/O on a suspended devices, the kernel will lock up. > > Second, there may be a memory allocation in progress when suspend is started > that causes I/O to happen and races with the suspend process. If the latter > wins the race, the I/O may be attempted on a suspended device and the kernel > will lock up.
I think the race happen itself is bad. memory and I/O subsystem can't solve such race elegantly. These doesn't know enough suspend state knowlege. I think the practical solution is that higher level design prevent the race happen.
> My patch attempts to avoid these two problems as well as the problem with > drivers using GFP_KERNEL allocations during suspend which I admit might be > solved by reworking the drivers.
Agreed. In this case, only drivers change can solve the issue.
| |