Messages in this thread | | | Date | Wed, 16 Jan 2013 15:37:44 -0800 | From | Andrew Morton <> | Subject | 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.lei@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?
| |