From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752563AbbKXIOg (ORCPT ); Tue, 24 Nov 2015 03:14:36 -0500 Received: from mail-pa0-f45.google.com ([209.85.220.45]:36378 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751251AbbKXIOf (ORCPT ); Tue, 24 Nov 2015 03:14:35 -0500 Date: Tue, 24 Nov 2015 17:14:26 +0900 From: Minchan Kim To: Sergey Senozhatsky Cc: Andrew Morton , linux-kernel@vger.kernel.org, Kyeongdon Kim , Sergey Senozhatsky Subject: Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Message-ID: <20151124081426.GB32717@blaptop> References: <1448337696-10689-1-git-send-email-minchan@kernel.org> <20151124061258.GJ705@swordfish> <20151124070311.GB7708@blaptop> <20151124073636.GA1254@swordfish> <20151124075707.GA32717@blaptop> <20151124080734.GB1254@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151124080734.GB1254@swordfish> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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