On Tue, Oct 19, 2010 at 11:03 AM, KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> wrote: >> On Tue, Oct 19, 2010 at 10:21 AM, KOSAKI Motohiro >> <kosaki.motohiro@xxxxxxxxxxxxxx> wrote: >> >> On Tue, Oct 19, 2010 at 9:57 AM, KOSAKI Motohiro >> >> <kosaki.motohiro@xxxxxxxxxxxxxx> wrote: >> >> >> > I think there are two bugs here. >> >> >> > The raid1 bug that Torsten mentions is certainly real (and has been around >> >> >> > for an embarrassingly long time). >> >> >> > The bug that I identified in too_many_isolated is also a real bug and can be >> >> >> > triggered without md/raid1 in the mix. >> >> >> > So this is not a 'full fix' for every bug in the kernel :-), but it could >> >> >> > well be a full fix for this particular bug. >> >> >> > >> >> >> >> >> >> Can we just delete the too_many_isolated() logic? (Crappy comment >> >> >> describes what the code does but not why it does it). >> >> > >> >> > if my remember is correct, we got bug report that LTP may makes misterious >> >> > OOM killer invocation about 1-2 years ago. because, if too many parocess are in >> >> > reclaim path, all of reclaimable pages can be isolated and last reclaimer found >> >> > the system don't have any reclaimable pages and lead to invoke OOM killer. >> >> > We have strong motivation to avoid false positive oom. then, some discusstion >> >> > made this patch. >> >> > >> >> > if my remember is incorrect, I hope Wu or Rik fix me. >> >> >> >> AFAIR, it's right. >> >> >> >> How about this? >> >> >> >> It's rather aggressive throttling than old(ie, it considers not lru >> >> type granularity but zone ) >> >> But I think it can prevent unnecessary OOM problem and solve deadlock problem. >> > >> > 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. > So, if anyone don't say Wu's one is wrong, I like his one. > I am not against it and just want to solve the problem without adding new logic. -- 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/ . Don't email: <a href