On Tue, Nov 24, 2015 at 05:07:34PM +0900, Sergey Senozhatsky wrote: > 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?
In [3/3], I used GFP_KERNEL for sysfs_store but with FS, you're absoultely right. I have no reason not to use GFP_NOIO in there. Thanks for the review! > > -ss -- Kind regards, Minchan Kim -- 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/