Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp5554695ybc; Wed, 27 Nov 2019 05:58:16 -0800 (PST) X-Google-Smtp-Source: APXvYqxGpzxH6R/p67MVNlQ2uzBmjzgIpWBYnPLQu2o4kftTR5CrsdQQvhcOlV/QETlxpGj01WBK X-Received: by 2002:a50:ec82:: with SMTP id e2mr32409242edr.68.1574863096328; Wed, 27 Nov 2019 05:58:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574863096; cv=none; d=google.com; s=arc-20160816; b=oNYMTZQgyanDZivCfg3webyRgqYl7h5/euNyD48haG2/dKjxHPdPkqMZhvy83yPSec ehntOeNsCOTi+Zsmxyt3l7y/lFmaPgyd0gyKTWq6PGkZciPj58Mk0YbMN1ozbh+2CWSf bcDZ2omG4nI1cGmcRu59ANo+OT49AzEfmWabbx/76CTvjXY8xeyVpRDAMpYW0pK4Se1p YV33N9niTYyHYtw4UernpdGrQBXtnhAdLQPoqIx20/xocJbdSlGz4G74Q4WVfr7Qs+Ku 1xnHB5HWn28mu25jUyRH20/0jQSOPc0gkhKStTGtM4U/9T+EPYPfQt41EAERXMXmqHK2 g+cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :reply-to:message-id:subject:cc:to:from:date; bh=ylrvkrHdZ1IxDHv9yBOkyKat9lUYSq+JlYOiAWZn2wU=; b=Rh+D5HY8R9QU7XMYqGu99ODIHBcXZcu9N7vwOPjBjJDvsvY+wDraGj8Kb9k3BNJNSd pa+t9+qqKqUAZFuE1DRg51Y1whQQjNcK8Ufam+3/c24JYA7wAIUyfnAsADq34JJlGfja nwfjfa06AbZuDxB31i7IUHKUDqo6inqxe+dA7OynkBsPQTGvdgqirLEJOMShQd4tPNrD Wi4dr5LXqMpoaQT8ayiD5KEuiyZFOzHgQSPVKJLFZyw/TdOPk4cs3AQha4dzuqewCT+7 T8JklFkH9bORqXAit9OOlfc+8BcPOVdsIu39Ayqw/31Gpq18oIfbj5q0vNyZUdCmAbAN uiPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o27si9458987ejb.408.2019.11.27.05.57.51; Wed, 27 Nov 2019 05:58:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727097AbfK0Nyl (ORCPT + 99 others); Wed, 27 Nov 2019 08:54:41 -0500 Received: from mx2.suse.de ([195.135.220.15]:35182 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726558AbfK0Nyk (ORCPT ); Wed, 27 Nov 2019 08:54:40 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DDB51AD54; Wed, 27 Nov 2019 13:54:38 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id A8D30DA733; Wed, 27 Nov 2019 14:54:36 +0100 (CET) Date: Wed, 27 Nov 2019 14:54:36 +0100 From: David Sterba To: Zaslonko Mikhail Cc: Josef Bacik , Andrew Morton , Chris Mason , David Sterba , Richard Purdie , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/5] btrfs: Increase buffer size for zlib functions Message-ID: <20191127135436.GR2734@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Zaslonko Mikhail , Josef Bacik , Andrew Morton , Chris Mason , David Sterba , Richard Purdie , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org References: <20191126144130.75710-1-zaslonko@linux.ibm.com> <20191126144130.75710-6-zaslonko@linux.ibm.com> <20191126155249.j2dktiggykfoz4iz@MacBook-Pro-91.local> <11377b99-b66c-fdc3-5c8f-0bae34c92c03@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11377b99-b66c-fdc3-5c8f-0bae34c92c03@linux.ibm.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 27, 2019 at 02:42:20PM +0100, Zaslonko Mikhail wrote: > Hello, > > On 26.11.2019 16:52, Josef Bacik wrote: > > On Tue, Nov 26, 2019 at 03:41:30PM +0100, Mikhail Zaslonko wrote: > >> Due to the small size of zlib buffer (1 page) set in btrfs code, s390 > >> hardware compression is rather limited in terms of performance. Increasing > >> the buffer size to 4 pages would bring significant benefit for s390 > >> hardware compression (up to 60% better performance compared to the > >> PAGE_SIZE buffer) and should not bring much overhead in terms of memory > >> consumption due to order 2 allocations. > >> > >> Signed-off-by: Mikhail Zaslonko > > > > We may have to make these allocations under memory pressure in the IO context, > > order 2 allocations here is going to be not awesome. If you really want it then > > you need to at least be able to fall back to single page if you fail to get the > > allocation. Thanks, > > As far as I understand GFP_KERNEL allocations would never fail for the order <= > PAGE_ALLOC_COSTLY_ORDER. There's no guaranteed no-fail semantics for GFP flags (obviously besides __GFP_NOFAIL), GFP_KERNEL can fail and GFP_NOFS is unlikely to fail for order below costly allocations. This depends on the allocator internals and has never been an API-level guarantee AFAIK. There's ongoing to work to relax the allocator constraints and allow to fail in more cases (like for GFP_NOFS). > How else can the memory pressure condition be identified > here? All data write paths must consider what happens under memory pressure, because the reason to write the data could be started by an allocation that can get free memory by writing dirty data. So it's kind of implied here.