Messages in this thread |  | | | Date | Mon, 25 Oct 2010 07:55:09 +0900 | | Subject | Re: [PATCH] mm: Avoid possible deadlock caused by too_many_isolated() | | From | Minchan Kim <> |
| |
On Fri, Oct 22, 2010 at 1:55 PM, Wu Fengguang <fengguang.wu@intel.com> wrote: > Neil find that if too_many_isolated() returns true while performing > direct reclaim we can end up waiting for other threads to complete their > direct reclaim. If those threads are allowed to enter the FS or IO to > free memory, but this thread is not, then it is possible that those > threads will be waiting on this thread and so we get a circular > deadlock. > > some task enters direct reclaim with GFP_KERNEL > => too_many_isolated() false > => vmscan and run into dirty pages > => pageout() > => take some FS lock > => fs/block code does GFP_NOIO allocation > => enter direct reclaim again > => too_many_isolated() true > => waiting for others to progress, however the other > tasks may be circular waiting for the FS lock.. > > The fix is to let !__GFP_IO and !__GFP_FS direct reclaims enjoy higher > priority than normal ones, by lowering the throttle threshold for the > latter. > > Allowing ~1/8 isolated pages in normal is large enough. For example, > for a 1GB LRU list, that's ~128MB isolated pages, or 1k blocked tasks > (each isolates 32 4KB pages), or 64 blocked tasks per logical CPU > (assuming 16 logical CPUs per NUMA node). So it's not likely some CPU > goes idle waiting (when it could make progress) because of this limit: > there are much more sleeping reclaim tasks than the number of CPU, so > the task may well be blocked by some low level queue/lock anyway. > > Now !GFP_IOFS reclaims won't be waiting for GFP_IOFS reclaims to > progress. They will be blocked only when there are too many concurrent > !GFP_IOFS reclaims, however that's very unlikely because the IO-less > direct reclaims is able to progress much more faster, and they won't > deadlock each other. The threshold is raised high enough for them, so > that there can be sufficient parallel progress of !GFP_IOFS reclaims. > > CC: Torsten Kaiser <just.for.lkml@googlemail.com> > CC: Minchan Kim <minchan.kim@gmail.com> > Tested-by: NeilBrown <neilb@suse.de> > Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |