On (11/24/15 16:57), Minchan Kim wrote: [..] > > hm, ok, may be. > > but the question whether we want to waste pages on additional streams > > (especially, e.g. if we already have, say, 10 streams) is still valid. > > a more intuitive here is to release some unneeded streams, not to increase > > our pressure allocating new ones. well, at least it seems to be so. > > those pages can be used by zsmalloc, for example. > > I think your claim make sense if the failure comes from high memory > pressure but order-3 alloc failure even if there are lots of order-0 > free pages in my experience is easy to encouter so I think it doesn't > mean memory pressure but just memory fragmentation.
hm, yes, fragmentation can be one of the reasons. > > > > ... and add GFP_NOIO to both kzalloc() and __vmalloc(). > > > > > > I can add it. The harmness is really ignorable but as I mentioned > > > at reply of Andrew, what's the benefit with GFP_NOIO? > > > We couldn't make forward progress with __GFP_RECLAIM in reclaim > > > context. > > > > aha, I probably missed that out. > > (well, and, technically, things can change). > > My speaking came from MM internal knowledge so I accept your concern. > if you prefer like GFP_NOIO, I will use it in next spin which > makes reader less confused. ok, I found your comment : It would be void *most of time* because it is called in reclaim context : and reclaim path bails out to avoid recursion of direct reclaim : by PF_MEMALLOC without trying reclaim. : However, the reason I said *most of time* is we has another context : the funcion could be called. well, we also allocate streams from sysfs store and during 'normal' IO (e.g. from fs). wouldn't GFP_NOIO be helpful there? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/