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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
