On Mon, Jan 10, 2011 at 03:56:37PM -0800, Hugh Dickins wrote: > On Mon, 10 Jan 2011, Mel Gorman wrote: > > This patch fixes makes the problem > > unreprodible for me at least. I still don't have the exact reason why pages are > > not getting unlocked by IO completion but suspect it's because the same process > > completes the IO that started it. If it's deadlocked, it never finishes the IO. > > It again seems fairly obvious to me, now that you've spelt it out for me > this far. If we go the mpage_readpages route, that builds up an mpage bio, > calling add_to_page_cache (which sets the locked bit) on a series of pages, > before submitting the bio whose mpage_end_io will unlock them all after. > An allocation when adding second or third... page is in danger of > deadlocking on the first page down in compaction's migration. Indeed. If we are lucky, all I/O requests are merged into just one bio and it will submit by mpage_bio_submit after finishing looping add_to_page_cache_lru. It is likely to make deadlock if direct compaction happens in the middle of looping. -- Kind regards, Minchan Kim -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>