On Thu, 17 Jan 2013 09:28:14 +0800 Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote: > > If so, I wonder if we could avoid the whole problem by appropriately > > syncing all dirty memory back to storage before starting to turn devices > > off? > > The patchset is to address the probable deadlock problem by GFP_KERNEL > during runtime suspend/resume which is per block/network device. I am > wondering if syncing all dirty memory is suitable or necessary during > per-storage/network device runtime resume/suspend: > > - sys_sync is very slow and runtime pm operation is frequent > > - it is not efficient because only sync dirty memory against the affected > device is needed in theory and not necessary to sync all > > - we still need some synchronization to avoid accessing the storage > between sys_sync and device suspend, just like system sleep case, > pm_restrict_gfp_mask is needed even sys_sync has been done > inside enter_state(). > > So looks the approach in the patch is simpler and more efficient, :-) > > Also, with the patchset, we can avoid many GFP_NOIO allocation > which is fragile and not easy to use. Fair enough, thanks. I grabbed the patches for 3.9-rc1. It is good that the page allocator's newly-added test of current->flags is not on the fastpath. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>