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