On Tue, 19 Oct 2010 00:15:04 +0800 Wu Fengguang <fengguang.wu@xxxxxxxxx> 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 honouring them higher throttle threshold. > > 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. I'm not sure that this is really a full fix. Torsten's analysis does appear to point at the real bug: raid1 has code paths which allocate more than a single element from a mempool without starting IO against previous elements. Giving these allocations the ability to dip further into reserves will make occurrence of the bug less likely, but if enough threads all do this at the same time, that reserve will be exhausted and we're back to square one? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>