Re: [PATCH v7 0/6] solve deadlock caused by memory allocation with I/O
On Fri, Jan 18, 2013 at 5:57 AM, Andrew Morton a...@linux-foundation.org wrote: 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. Andrew, great thanks, :-) Also thank Alan, Oliver, Minchan, Rafael, Greg and other guys who reviewed and gave suggestions on this patch set. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/6] solve deadlock caused by memory allocation with I/O
On Thursday 17 January 2013 09:28:14 Ming Lei wrote: - 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, Even worse. The memory may be needed to resume and the reason we need to resume may be that we need to write out memory. And there is no way to make sure we don't dirty memory unless user space is frozen, so it is either this approach, or GFP_NOIO in the whole resume code path. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/6] solve deadlock caused by memory allocation with I/O
On Thu, 17 Jan 2013 09:28:14 +0800 Ming Lei ming@canonical.com 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 from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/6] solve deadlock caused by memory allocation with I/O
On Sat, 5 Jan 2013 10:25:38 +0800 Ming Lei ming@canonical.com wrote: This patchset try to solve one deadlock problem which might be caused by memory allocation with block I/O during runtime PM and block device error handling path. Traditionly, the problem is addressed by passing GFP_NOIO statically to mm, but that is not a effective solution, see detailed description in patch 1's commit log. This patch set introduces one process flag and trys to fix the deadlock problem on block device/network device during runtime PM or usb bus reset. The patchset doesn't look like the worst thing I've ever applied ;) One thing I'm wondering: during suspend and resume, why are GFP_KERNEL allocation attempts even getting down to the device layer? Presumably the page scanner is encountering dirty pagecache or dirty swapcache pages? 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? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/6] solve deadlock caused by memory allocation with I/O
On Thu, Jan 17, 2013 at 7:37 AM, Andrew Morton a...@linux-foundation.org wrote: On Sat, 5 Jan 2013 10:25:38 +0800 Ming Lei ming@canonical.com wrote: This patchset try to solve one deadlock problem which might be caused by memory allocation with block I/O during runtime PM and block device error handling path. Traditionly, the problem is addressed by passing GFP_NOIO statically to mm, but that is not a effective solution, see detailed description in patch 1's commit log. This patch set introduces one process flag and trys to fix the deadlock problem on block device/network device during runtime PM or usb bus reset. The patchset doesn't look like the worst thing I've ever applied ;) One thing I'm wondering: during suspend and resume, why are GFP_KERNEL allocation attempts even getting down to the device layer? Presumably the page scanner is encountering dirty pagecache or dirty swapcache pages? 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. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
