diff for duplicates of <5407F124.5070203@oracle.com> diff --git a/a/1.txt b/N1/1.txt index 28005d5..aafa39e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -49,75 +49,3 @@ Even without this ocfs2 deadlock bug, the implement of PF_MEMALLOC_NOIO is wrong. See the deadlock case described in its log below. Let see the case "block device runtime resume", since __GFP_FS is not cleared, it could run into fs writepage and cause deadlock. - - ->From 21caf2fc1931b485483ddd254b634fa8f0099963 Mon Sep 17 00:00:00 2001 -From: Ming Lei <ming.lei@canonical.com> -Date: Fri, 22 Feb 2013 16:34:08 -0800 -Subject: [PATCH] mm: teach mm by current context info to not do I/O during - memory allocation - -This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of -'struct task_struct'), so that the flag can be set by one task to avoid -doing I/O inside memory allocation in the task's context. - -The patch trys to solve one deadlock problem caused by block device, and -the problem may happen at least in the below situations: - -- during block device runtime resume, if memory allocation with - GFP_KERNEL is called inside runtime resume callback of any one of its - ancestors(or the block device itself), the deadlock may be triggered - inside the memory allocation since it might not complete until the block - device becomes active and the involed page I/O finishes. The situation - is pointed out first by Alan Stern. It is not a good approach to - convert all GFP_KERNEL[1] in the path into GFP_NOIO because several - subsystems may be involved(for example, PCI, USB and SCSI may be - involved for usb mass stoarage device, network devices involved too in - the iSCSI case) - -- during block device runtime suspend, because runtime resume need to - wait for completion of concurrent runtime suspend. - -- during error handling of usb mass storage deivce, USB bus reset will - be put on the device, so there shouldn't have any memory allocation with - GFP_KERNEL during USB bus reset, otherwise the deadlock similar with - above may be triggered. Unfortunately, any usb device may include one - mass storage interface in theory, so it requires all usb interface - drivers to handle the situation. In fact, most usb drivers don't know - how to handle bus reset on the device and don't provide .pre_set() and - .post_reset() callback at all, so USB core has to unbind and bind driver - for these devices. So it is still not practical to resort to GFP_NOIO - for solving the problem. - -Thanks, -Junxiao. -> ->>> ->>> And the superblock shrinker is a good example of why this shouldn't be ->>> the case. The main thing that code does is to reclaim clean fs objects ->>> without performing IO. AFAICT the proposed patch will significantly ->>> weaken PF_MEMALLOC_NOIO allocation attempts by needlessly preventing ->>> the kernel from reclaiming such objects? ->> Even fs didn't do io in superblock shrinker, it is possible for a fs ->> process who is not convenient to set GFP_NOFS holding some fs lock and ->> call back fs again? ->> ->> PF_MEMALLOC_NOIO is only set for some special processes. I think it ->> won't affect much. -> -> Maybe not now. But once we add hacks like this, people say "goody" and -> go and use them rather than exerting the effort to sort out their -> deadlocks properly :( There will be more PF_MEMALLOC_NOIO users in -> 2019. -> -> Dunno, I'd like to hear David's thoughts but perhaps it would be better -> to find some way to continue to permit PF_MEMALLOC_NOIO to shrink VFS -> caches for most filesystems and find some fs-specific fix for ocfs2. -> That would mean testing PF_MEMALLOC_NOIO directly I guess. -> - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index ce406a6..6d56b65 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -64,78 +64,6 @@ "Even without this ocfs2 deadlock bug, the implement of PF_MEMALLOC_NOIO\n" "is wrong. See the deadlock case described in its log below. Let see the\n" "case \"block device runtime resume\", since __GFP_FS is not cleared, it\n" - "could run into fs writepage and cause deadlock.\n" - "\n" - "\n" - ">From 21caf2fc1931b485483ddd254b634fa8f0099963 Mon Sep 17 00:00:00 2001\n" - "From: Ming Lei <ming.lei@canonical.com>\n" - "Date: Fri, 22 Feb 2013 16:34:08 -0800\n" - "Subject: [PATCH] mm: teach mm by current context info to not do I/O during\n" - " memory allocation\n" - "\n" - "This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of\n" - "'struct task_struct'), so that the flag can be set by one task to avoid\n" - "doing I/O inside memory allocation in the task's context.\n" - "\n" - "The patch trys to solve one deadlock problem caused by block device, and\n" - "the problem may happen at least in the below situations:\n" - "\n" - "- during block device runtime resume, if memory allocation with\n" - " GFP_KERNEL is called inside runtime resume callback of any one of its\n" - " ancestors(or the block device itself), the deadlock may be triggered\n" - " inside the memory allocation since it might not complete until the block\n" - " device becomes active and the involed page I/O finishes. The situation\n" - " is pointed out first by Alan Stern. It is not a good approach to\n" - " convert all GFP_KERNEL[1] in the path into GFP_NOIO because several\n" - " subsystems may be involved(for example, PCI, USB and SCSI may be\n" - " involved for usb mass stoarage device, network devices involved too in\n" - " the iSCSI case)\n" - "\n" - "- during block device runtime suspend, because runtime resume need to\n" - " wait for completion of concurrent runtime suspend.\n" - "\n" - "- during error handling of usb mass storage deivce, USB bus reset will\n" - " be put on the device, so there shouldn't have any memory allocation with\n" - " GFP_KERNEL during USB bus reset, otherwise the deadlock similar with\n" - " above may be triggered. Unfortunately, any usb device may include one\n" - " mass storage interface in theory, so it requires all usb interface\n" - " drivers to handle the situation. In fact, most usb drivers don't know\n" - " how to handle bus reset on the device and don't provide .pre_set() and\n" - " .post_reset() callback at all, so USB core has to unbind and bind driver\n" - " for these devices. So it is still not practical to resort to GFP_NOIO\n" - " for solving the problem.\n" - "\n" - "Thanks,\n" - "Junxiao.\n" - "> \n" - ">>>\n" - ">>> And the superblock shrinker is a good example of why this shouldn't be\n" - ">>> the case. The main thing that code does is to reclaim clean fs objects\n" - ">>> without performing IO. AFAICT the proposed patch will significantly\n" - ">>> weaken PF_MEMALLOC_NOIO allocation attempts by needlessly preventing\n" - ">>> the kernel from reclaiming such objects?\n" - ">> Even fs didn't do io in superblock shrinker, it is possible for a fs\n" - ">> process who is not convenient to set GFP_NOFS holding some fs lock and\n" - ">> call back fs again?\n" - ">>\n" - ">> PF_MEMALLOC_NOIO is only set for some special processes. I think it\n" - ">> won't affect much.\n" - "> \n" - "> Maybe not now. But once we add hacks like this, people say \"goody\" and\n" - "> go and use them rather than exerting the effort to sort out their\n" - "> deadlocks properly :( There will be more PF_MEMALLOC_NOIO users in\n" - "> 2019.\n" - "> \n" - "> Dunno, I'd like to hear David's thoughts but perhaps it would be better\n" - "> to find some way to continue to permit PF_MEMALLOC_NOIO to shrink VFS\n" - "> caches for most filesystems and find some fs-specific fix for ocfs2. \n" - "> That would mean testing PF_MEMALLOC_NOIO directly I guess.\n" - "> \n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + could run into fs writepage and cause deadlock. -1e43f27918f229281d37f93b3381bd1d6c281014474795a15282c9f5a4104753 +377fc6727cb964a7b0b50d93598de08e3da7dcbd985a9f784958c79b7aa278eb
diff --git a/a/1.txt b/N2/1.txt index 28005d5..290725b 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -114,10 +114,4 @@ Junxiao. > to find some way to continue to permit PF_MEMALLOC_NOIO to shrink VFS > caches for most filesystems and find some fs-specific fix for ocfs2. > That would mean testing PF_MEMALLOC_NOIO directly I guess. -> - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> +> diff --git a/a/content_digest b/N2/content_digest index ce406a6..14a5528 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -130,12 +130,6 @@ "> to find some way to continue to permit PF_MEMALLOC_NOIO to shrink VFS\n" "> caches for most filesystems and find some fs-specific fix for ocfs2. \n" "> That would mean testing PF_MEMALLOC_NOIO directly I guess.\n" - "> \n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + > -1e43f27918f229281d37f93b3381bd1d6c281014474795a15282c9f5a4104753 +14f4bf7ed12f3570e0eda2d5c19973c5b422dc73162017ff21e71e8b5d244faa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.