From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753120AbbKXEkl (ORCPT ); Mon, 23 Nov 2015 23:40:41 -0500 Received: from mail-pa0-f45.google.com ([209.85.220.45]:33049 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750830AbbKXEkj (ORCPT ); Mon, 23 Nov 2015 23:40:39 -0500 Date: Tue, 24 Nov 2015 13:41:39 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , Kyeongdon Kim , Sergey Senozhatsky , linux-kernel@vger.kernel.org Subject: Re: [PATCH] zram/zcomp: use GFP_NOIO to allocate streams Message-ID: <20151124044139.GF705@swordfish> References: <1448285279-4013-1-git-send-email-sergey.senozhatsky@gmail.com> <20151123151812.a335f9a52abd74d7017ecd85@linux-foundation.org> <20151124003027.GA705@swordfish> <20151123164740.495e5067d9d45a7f98b5ace3@linux-foundation.org> <20151124012927.GC705@swordfish> <20151124041341.GB11115@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151124041341.GB11115@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 13:13), Minchan Kim wrote: > First of all, Thanks for the summary and proposal. sure :) > I think GFP_NOIO critical part(ie, your lockdep fix patch) should > go to -stable so it should stand alone. > > About vmalloc, I like that. Just problem was gfp and we can > pass it from upper layer so I believe it makes code looks clean > and solve differnt gfp problem. doing vmalloc() after kmalloc in general looks ok, but the thing is that kmalloc()->vmalloc() fallback does not mean that stream allocation will end up being successful, because right after ->private we need to allocate ->buffer via __get_free_pages() and that thing can fail. so trying harder in comp->backend->create() is just half of what we need. but the question is -- do we have a really big reason to fallback in ->private allocation? we are quite prepared to handle that allocation failure and I tend to think that in low memory condition it's probably better to avoid stealing pages for additional streams; one stream is just enough, if we are lucky to have more than one stream by that time -- then fine. > Please look at my patchset I just sent. I'll take a look once I receive them (not in my inbox yet). -ss