> >> > Can you please elaborate your intention? Do you think Wu's approach is wrong? > >> > >> No. I think Wu's patch may work well. But I agree Andrew. > >> Couldn't we remove the too_many_isolated logic? If it is, we can solve > >> the problem simply. > >> But If we remove the logic, we will meet long time ago problem, again. > >> So my patch's intention is to prevent OOM and deadlock problem with > >> simple patch without adding new heuristic in too_many_isolated. > > > > But your patch is much false positive/negative chance because isolated pages timing > > and too_many_isolated_zone() call site are in far distance place. > > Yes. > How about the returning *did_some_progress can imply too_many_isolated > fail by using MSB or new variable? > Then, page_allocator can check it whether it causes read reclaim fail > or parallel reclaim. > The point is let's throttle without holding FS/IO lock. Wu's version sleep in shrink_inactive_list(). your version sleep in __alloc_pages_slowpath() by wait_iff_congested(). both don't release lock, I think. But, if alloc_pages() return fail if GFP_NOIO, we introduce another issue. -- 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>