> > Many applications (this one and below) are stuck in > > wait_on_page_writeback(). I guess this is why "heavy write to > > irrelevant partition stalls the whole system". They are stuck on page > > allocation. Your 512MB system memory is a bit tight, so reclaim > > pressure is a bit high, which triggers the wait-on-writeback logic. > > I wonder if this hacking patch may help. > > When creating 300MB dirty file with dd, it is creating continuous > region of hard-to-reclaim pages in the LRU list. priority can easily > go low when irrelevant applications' direct reclaim run into these > regions.. Sorry I'm confused not. can you please tell us more detail explanation? Why did lumpy reclaim cause OOM? lumpy reclaim might cause direct reclaim slow down. but IIUC it's not cause OOM because OOM is only occur when priority-0 reclaim failure. IO get stcking also prevent priority reach to 0. > > Thanks, > Fengguang > --- > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index e0e5f15..f7179cf 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1149,7 +1149,7 @@ static unsigned long shrink_inactive_list(unsigned long max_scan, > */ > if (sc->order > PAGE_ALLOC_COSTLY_ORDER) > lumpy_reclaim = 1; > - else if (sc->order && priority < DEF_PRIORITY - 2) > + else if (sc->order && priority < DEF_PRIORITY / 2) > lumpy_reclaim = 1; > > pagevec_init(&pvec, 1); > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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>