From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0441EC48BD1 for ; Thu, 10 Jun 2021 16:23:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DEC9560C40 for ; Thu, 10 Jun 2021 16:23:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231268AbhFJQZd (ORCPT ); Thu, 10 Jun 2021 12:25:33 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:60036 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231230AbhFJQZ3 (ORCPT ); Thu, 10 Jun 2021 12:25:29 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id AF84E2199E; Thu, 10 Jun 2021 16:23:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1623342211; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KjKhr3a6YXymIHtw/GA/lThxHjdin/LlLBM4rjmo30o=; b=OaCK2JwDCJzSG8mw0/KxhlY24EZJYzmrY1pCXj1ftvfhrFWiJeWwKCF6VRt/3GNGIZQTKI 64uAumwxrCoYdgNTs61JjnnHSiudVprP6OUXn6eQhEtgRh2PJr0hss4Xc4UV44n8M0sx8X PenUaTJWzag3UNmGuL8gosguy0gx3Mk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1623342211; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KjKhr3a6YXymIHtw/GA/lThxHjdin/LlLBM4rjmo30o=; b=Q1+SIX5fmet/R8yDOZj1UmQUYKVKEEmnbImI7UgkAOw2mAruK7BtMq2iRopww2P1n1GTgZ Q69a5hyw9tRxW6Cg== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id 6326CA3B93; Thu, 10 Jun 2021 16:23:31 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id C6DC9DAEB9; Thu, 10 Jun 2021 18:20:46 +0200 (CEST) Date: Thu, 10 Jun 2021 18:20:46 +0200 From: David Sterba To: Christophe Leroy Cc: Chris Mason , Josef Bacik , David Sterba , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , linux-btrfs , "linux-hexagon@vger.kernel.org" Subject: Re: [PATCH] btrfs: Disable BTRFS on platforms having 256K pages Message-ID: <20210610162046.GB28158@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Christophe Leroy , Chris Mason , Josef Bacik , David Sterba , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , linux-btrfs , "linux-hexagon@vger.kernel.org" References: <185278AF-1D87-432D-87E9-C86B3223113E@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 10, 2021 at 04:50:09PM +0200, Christophe Leroy wrote: > > > Le 10/06/2021 à 15:54, Chris Mason a écrit : > > > >> On Jun 10, 2021, at 1:23 AM, Christophe Leroy wrote: > >> > >> With a config having PAGE_SIZE set to 256K, BTRFS build fails > >> with the following message > >> > >> include/linux/compiler_types.h:326:38: error: call to '__compiletime_assert_791' declared with attribute error: BUILD_BUG_ON failed: (BTRFS_MAX_COMPRESSED % PAGE_SIZE) != 0 > >> > >> BTRFS_MAX_COMPRESSED being 128K, BTRFS cannot support platforms with > >> 256K pages at the time being. > >> > >> There are two platforms that can select 256K pages: > >> - hexagon > >> - powerpc > >> > >> Disable BTRFS when 256K page size is selected. > >> > > > > We’ll have other subpage blocksize concerns with 256K pages, but this BTRFS_MAX_COMPRESSED #define is arbitrary. It’s just trying to have an upper bound on the amount of memory we’ll need to uncompress a single page’s worth of random reads. > > > > We could change it to max(PAGE_SIZE, 128K) or just bump to 256K. > > > > But if 256K is problematic in other ways, is it worth bumping BTRFS_MAX_COMPRESSED to 256K ? > > David, in below mail, said that 256K support would require deaper changes. So disabling BTRFS > support seems the easiest solution for the time being, at least for Stable (I forgot the Fixes: tag > and the CC: to stable). > > On powerpc, 256k pages is a corner case, it requires customised binutils, so I don't think disabling > BTRFS is a issue there. For hexagon I don't know. That it blew up due to the max compressed size is a coincidence. We could have explicit BUILD_BUG_ONs for page size or other constraints derived from the page size like INLINE_EXTENT_BUFFER_PAGES. And there's no such thing like "just bump BTRFS_MAX_COMPRESSED to 256K". The constant is part of on-disk format for lzo and otherwise changing it would impact performance so this would need proper evaluation. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1F7FC47094 for ; Thu, 10 Jun 2021 16:34:01 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0E23361362 for ; Thu, 10 Jun 2021 16:34:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E23361362 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4G18gW63dDz3byY for ; Fri, 11 Jun 2021 02:33:59 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=suse.cz header.i=@suse.cz header.a=rsa-sha256 header.s=susede2_rsa header.b=OaCK2JwD; dkim=fail reason="signature verification failed" header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=Q1+SIX5f; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=suse.cz (client-ip=195.135.220.28; helo=smtp-out1.suse.de; envelope-from=dsterba@suse.cz; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=suse.cz header.i=@suse.cz header.a=rsa-sha256 header.s=susede2_rsa header.b=OaCK2JwD; dkim=pass header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=Q1+SIX5f; dkim-atps=neutral X-Greylist: delayed 594 seconds by postgrey-1.36 at boromir; Fri, 11 Jun 2021 02:33:31 AEST Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4G18fz2L4Wz305k for ; Fri, 11 Jun 2021 02:33:30 +1000 (AEST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id AF84E2199E; Thu, 10 Jun 2021 16:23:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1623342211; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KjKhr3a6YXymIHtw/GA/lThxHjdin/LlLBM4rjmo30o=; b=OaCK2JwDCJzSG8mw0/KxhlY24EZJYzmrY1pCXj1ftvfhrFWiJeWwKCF6VRt/3GNGIZQTKI 64uAumwxrCoYdgNTs61JjnnHSiudVprP6OUXn6eQhEtgRh2PJr0hss4Xc4UV44n8M0sx8X PenUaTJWzag3UNmGuL8gosguy0gx3Mk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1623342211; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KjKhr3a6YXymIHtw/GA/lThxHjdin/LlLBM4rjmo30o=; b=Q1+SIX5fmet/R8yDOZj1UmQUYKVKEEmnbImI7UgkAOw2mAruK7BtMq2iRopww2P1n1GTgZ Q69a5hyw9tRxW6Cg== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id 6326CA3B93; Thu, 10 Jun 2021 16:23:31 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id C6DC9DAEB9; Thu, 10 Jun 2021 18:20:46 +0200 (CEST) Date: Thu, 10 Jun 2021 18:20:46 +0200 From: David Sterba To: Christophe Leroy Subject: Re: [PATCH] btrfs: Disable BTRFS on platforms having 256K pages Message-ID: <20210610162046.GB28158@suse.cz> Mail-Followup-To: dsterba@suse.cz, Christophe Leroy , Chris Mason , Josef Bacik , David Sterba , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , linux-btrfs , "linux-hexagon@vger.kernel.org" References: <185278AF-1D87-432D-87E9-C86B3223113E@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: dsterba@suse.cz Cc: "linux-hexagon@vger.kernel.org" , Josef Bacik , "linux-kernel@vger.kernel.org" , Chris Mason , David Sterba , "linuxppc-dev@lists.ozlabs.org" , linux-btrfs Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jun 10, 2021 at 04:50:09PM +0200, Christophe Leroy wrote: > > > Le 10/06/2021 à 15:54, Chris Mason a écrit : > > > >> On Jun 10, 2021, at 1:23 AM, Christophe Leroy wrote: > >> > >> With a config having PAGE_SIZE set to 256K, BTRFS build fails > >> with the following message > >> > >> include/linux/compiler_types.h:326:38: error: call to '__compiletime_assert_791' declared with attribute error: BUILD_BUG_ON failed: (BTRFS_MAX_COMPRESSED % PAGE_SIZE) != 0 > >> > >> BTRFS_MAX_COMPRESSED being 128K, BTRFS cannot support platforms with > >> 256K pages at the time being. > >> > >> There are two platforms that can select 256K pages: > >> - hexagon > >> - powerpc > >> > >> Disable BTRFS when 256K page size is selected. > >> > > > > We’ll have other subpage blocksize concerns with 256K pages, but this BTRFS_MAX_COMPRESSED #define is arbitrary. It’s just trying to have an upper bound on the amount of memory we’ll need to uncompress a single page’s worth of random reads. > > > > We could change it to max(PAGE_SIZE, 128K) or just bump to 256K. > > > > But if 256K is problematic in other ways, is it worth bumping BTRFS_MAX_COMPRESSED to 256K ? > > David, in below mail, said that 256K support would require deaper changes. So disabling BTRFS > support seems the easiest solution for the time being, at least for Stable (I forgot the Fixes: tag > and the CC: to stable). > > On powerpc, 256k pages is a corner case, it requires customised binutils, so I don't think disabling > BTRFS is a issue there. For hexagon I don't know. That it blew up due to the max compressed size is a coincidence. We could have explicit BUILD_BUG_ONs for page size or other constraints derived from the page size like INLINE_EXTENT_BUFFER_PAGES. And there's no such thing like "just bump BTRFS_MAX_COMPRESSED to 256K". The constant is part of on-disk format for lzo and otherwise changing it would impact performance so this would need proper evaluation.