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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BCE1C6FD1D for ; Tue, 21 Mar 2023 15:26:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCD106B0078; Tue, 21 Mar 2023 11:26:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B7C346B007B; Tue, 21 Mar 2023 11:26:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A44746B007D; Tue, 21 Mar 2023 11:26:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9575E6B0078 for ; Tue, 21 Mar 2023 11:26:30 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6B0F2A0115 for ; Tue, 21 Mar 2023 15:26:30 +0000 (UTC) X-FDA: 80593282140.25.803D853 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf05.hostedemail.com (Postfix) with ESMTP id 6464E100016 for ; Tue, 21 Mar 2023 15:26:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=BqM2UZjm; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=kh4QJnPp; spf=pass (imf05.hostedemail.com: domain of hare@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=hare@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679412388; h=from:from:sender:reply-to:subject:subject: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:dkim-signature; bh=fHCbxvEjKOCYot1TTU/89XdN70pMiGLRyCU4Q3dVZWM=; b=nFbne208Ho9nyKU6oXrEUqfpi52wofzOdfYhQ8VbEkdfTT0ae6AKijxQSkfLvA9FDR+VFn vbX9i0xrTrBt9UFD0IQiVwN9ShYN5WzkgqrQm5uD6BMO95U5eOqhcV+iBCEkqMNRodFWu5 102MsOZrlBgrgMMQ4EilbvYXJIVYRWg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=BqM2UZjm; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=kh4QJnPp; spf=pass (imf05.hostedemail.com: domain of hare@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=hare@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679412388; a=rsa-sha256; cv=none; b=ypCJJjXpQokrgnTVdzGA2bql5gVRCPEnfc0E5UnsVZLDc4UtFcWDS1BjqbypufL+gmJlJM CyZ/ZzBCoeeIP/hLlhOfumIDNOBt6B1bgiwl71ESuYIVxCJKZuLLfKedJ44Qxf0nXWO0yS yZINqohmouslIrJP+yEi3MUnHqu9UgY= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 06D9A201A2; Tue, 21 Mar 2023 15:26:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1679412387; h=from:from: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=fHCbxvEjKOCYot1TTU/89XdN70pMiGLRyCU4Q3dVZWM=; b=BqM2UZjmV8ztE6hEHNUxaqezY8+lLRir4PU85eB4qM5Y/TUYY2Yqir8fVHhaUCmOEEEy9W CKpCu6RRvUknfCahvnkNJlKbnWxZhYBpgaCuOkEMV++tgnfWPPMVSqyqFHBoeK59P1z71L 6jJ0t/citRikS93ERyilEzC4AYqwjOU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1679412387; h=from:from: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=fHCbxvEjKOCYot1TTU/89XdN70pMiGLRyCU4Q3dVZWM=; b=kh4QJnPp6A9z1s/gk+Je+Xxosy5KRUVMUm0VW6U7uzbHD+HZeeMv0Ob6U4C/5Mc5XletR+ PG+uzlQE9zmvrcAw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E4A9113440; Tue, 21 Mar 2023 15:26:26 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DQ0UN6LMGWRrWAAAMHmgww (envelope-from ); Tue, 21 Mar 2023 15:26:26 +0000 Message-ID: <0e54cc51-e667-b343-74b0-4989e28d8982@suse.de> Date: Tue, 21 Mar 2023 16:26:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 1/5] brd: convert to folios Content-Language: en-US To: Matthew Wilcox Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20230306120127.21375-1-hare@suse.de> <20230306120127.21375-2-hare@suse.de> <76613838-fa4c-7f3e-3417-7a803fafc6c2@suse.de> From: Hannes Reinecke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6464E100016 X-Stat-Signature: go7hjyisp9dzzq8t3m5g4jz3g1diz9jn X-HE-Tag: 1679412388-26939 X-HE-Meta: U2FsdGVkX1+cw6v5aHDEMhgS4e4Q1YVFQrX4eIMGZYtjlOzNse4sJbSQHqCiRNUxcztoKaK/RYGgmMgGB29dedikvYYSUAhSK6zEYfb4DJovOKDyi91Netphs4f7A+5BB9G9ZsKGeZLIT9pOg/1phFdE+TswqaR7ARiU/bwrUPA/nNxqllf/shtDf9vO34vyPrMuagH8wMqFj8qUKogKEEm34d0q/V90R6Dsz/qf8HdRo+CGXLRJVUx1iI7S9zUAAxhlR3PSgLqqSNhO43d/18T6LAwXI/exPPipvaaODCLW7QRFhnhHNGEXSkfB3yJ99N5HTe4K6L8Sv5uSIlZa1dtuDBoL3bN96MxkivlffbjZsH8ji6O1oJ/Eu5ye5+qxmiIN/5MMMN2z6KJCkHwEGmgp4JzniXXK2MA6bwtBOXjaKdJec/RkiPMTnh9q/I965sMx+pccaLIrEeiK7Ui28fxFJRc82UFTxpa/aFy5QaAiC9XKLucq7HVRdqKngRO+rDe5N7PatL2CakA8gQdMYtBpv/f5VuVBFjr1mdgOcZZHF/v0n+yEsYC9cZTvC3/OVcwHD80yrl0zu5BW74Bz+L2VBO4EzGcsh5Cz82PZHNs2eQhEzwopQxE3uOFybZ8q+muuWEkZXt9e+AgUJOKMEUNWjMoE855Bc4+TaHKTF3ZjR6bcW8Jcz4ECzXgHMADqjvC8f1rPv+apDydsJhAgBaXCzWXnYac/G0ViR0wHlovtQDervX43aU/4OqvIuVvbR6Euqz0VNWOk9an3UUFIuSXvlXlxtpUIBETUJaRMKX5tQ+vae+oBgGgMimbc+QPZLGpDILOaKvUoFj03Sj+p4NLHWW/zdrMTYrQoSnbH4ToczPKCU4HFfQqFyibdHVUGZUQH0OOrS2a/d2jbf6S8IxBINMyUN3H304rErvNTe/bPmoFSQhObndqw7Lus9vQU4Flm0nak4XlIcmahmRX bAqOWPQC XoGqvujaVm239CPjGxnfMgx4yJvDmVLAP6e5upZwYEg/Wwtcp2sW2+wEYSrOsAD/51ZydrdgHvf7nMpHCYnRp4vUYrBwWPcbsRSYKps0I9uHEHgpbbxyA9LIGA/zrXRG7oGJc886dD2UjWLWtm3CytxHd2lOrf5fW+pC/218V0CtRf8xxmddl14JH6NQK3najWMWE1V4ldutTpzG6PL+Cadn59Wzcm5bYGZQG7BjjCFj3/nY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/21/23 16:00, Matthew Wilcox wrote: > On Tue, Mar 07, 2023 at 09:14:27AM +0100, Hannes Reinecke wrote: >> On 3/7/23 08:30, Matthew Wilcox wrote: >>> On Tue, Mar 07, 2023 at 07:55:32AM +0100, Hannes Reinecke wrote: >>>> On 3/6/23 18:37, Matthew Wilcox wrote: >>>>> On Mon, Mar 06, 2023 at 01:01:23PM +0100, Hannes Reinecke wrote: >>>>>> - page = alloc_page(gfp | __GFP_ZERO | __GFP_HIGHMEM); >>>>>> - if (!page) >>>>>> + folio = folio_alloc(gfp | __GFP_ZERO, 0); >>>>>> + if (!folio) >>>>> >>>>> Did you drop HIGHMEM support on purpose? >>>> >>>> No; I thought that folios would be doing that implicitely. >>>> Will be re-adding. >>> >>> We can't ... not all filesystems want to allocate every folio from >>> HIGHMEM. eg for superblocks, it often makes more sense to allocate the >>> folio from lowmem than allocate it from highmem and keep it kmapped. >>> The only GFP flag that folios force-set is __GFP_COMP because folios by >>> definition are compound pages. >> >> Oh well. >> >> However, when playing with the modified brd and setting the logical&physical >> blocksize to 16k the whole thing crashes >> (not unexpectedly). >> It does crash, however, in block_read_full_folio(), which rather >> surprisingly (at least for me) is using create_page_buffers(); >> I would have expected something like create_folio_buffers(). >> Is this work in progress or what is the plan here? > > Supporting folios > PAGE_SIZE in blockdev is definitely still WIP. > I know of at least one bug, which is: > > #define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK) > > That needs to be something like > > static size_t bh_offset(const struct buffer_head *bh) > { > return (unsigned long)bh->b_data & (folio_size(bh->b_folio) - 1); > } > > I haven't done a thorough scan for folio-size problems in the block > layer; I've just been fixing up things as I notice them. > And not to mention the various instances of (PAGE_SHIFT - blkbits) which will get happily into negative numbers for large block sizes, resulting in interesting effects for a shift left operation ... > Yes, create_page_buffers() should now be create_folio_buffers(). Just > didn't get round to it yet. Ah, so I was on the right track after all. But I was wondering ... couldn't we use the physical block size as a hint on how many pages to allocate? With that we can work on updating the stack even with existing hardware, and we wouldn't crash immediately if we miss the odd conversion ... Hmm? Cheers, Hannes