> 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? -- 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