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 87A99C7EE23 for ; Wed, 1 Mar 2023 05:01:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1107F6B0073; Wed, 1 Mar 2023 00:01:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C17B6B0074; Wed, 1 Mar 2023 00:01:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECAE96B0075; Wed, 1 Mar 2023 00:01:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DE1086B0073 for ; Wed, 1 Mar 2023 00:01:49 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B61941610AC for ; Wed, 1 Mar 2023 05:01:49 +0000 (UTC) X-FDA: 80519131938.21.66655C5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 1CE68100005 for ; Wed, 1 Mar 2023 05:01:47 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BN3hiqzT; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677646908; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wWYaIDhPfuYqJ2OXFt7mummGj+i8spnErr9hehQauOo=; b=bAkXOjj9Vm0m5ZrVgjkE/eNYIq9wIRyI4ps28l5bjfcgulv5w+NDf6zhCxh97e1OoylbFt uUFSacC+dgsqFBWRk0/Na2gdlsZpt4eRZMaZO9B/InqjqaOKAQ0Kfk4cxFPpEiz3KdlW8/ pZ4ZPrpZ3l4BE+pOHTNE+iByf2nE1a4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BN3hiqzT; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677646908; a=rsa-sha256; cv=none; b=AwEebbg8WrHJ8Nqvq+9TbDKMK9mGTLDRfQJPTirTAIc6VEocNbxTwO0ju0+UFGJn6IOsG1 WAsUb9aE/WWsF0N2JLgzb/sO3BKcdEHR4iqILaIbAxtbBdewFrIVS/o1sJw+NDX7nj/MAQ /O8C34r8lOmsR6YUOsi2jEo/B5G8hWM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=wWYaIDhPfuYqJ2OXFt7mummGj+i8spnErr9hehQauOo=; b=BN3hiqzTsKGSSMlkXXJ9+ZT8dT 2aXKT3je9AZw91y+nvcZ9DMd1wZTQ3UzdrqEKtpHoKKXfySjmC+z0tNmVprKqjr7V0Du8vXrrcq14 vQsEk3WmsjFGsEl42b90Ml/xjlnG2DR/2f653kgbIt6Zo1H5YLbSiasn4tr4AUT2UxihTutKqNW6W Q51JdkxSz9xUp7TSdZYWxnhwLpcnBAv4qoMQsMHEoHzipXV1/xRD3XDl+yIX0lwvNwlJtZhX+g1nO QjtkDX1rWmfijAT78RNbbE6Qx6oDUa39HhDqiUrcJw7j3IfDyIiG9byElrcMfoMaAKh9QiVtX3hD8 XHA+YHNA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pXEaz-001OG7-GD; Wed, 01 Mar 2023 05:01:41 +0000 Date: Wed, 1 Mar 2023 05:01:41 +0000 From: Matthew Wilcox To: Gao Xiang Cc: Theodore Ts'o , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org Subject: Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 1CE68100005 X-Stat-Signature: r9nc6fqyrjio6ftteexwzatbhay3w9qb X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677646907-57526 X-HE-Meta: U2FsdGVkX19nS/0J5/XnOcwPasH1uLEyuhxRtBM9HRM4Duk2i13AOdaosc01aNdxCQCZfSM5svPVF9rQJDoBwaVbF0FR6HKbUmOeQ/5wieA6/4Hgot61gmpMmx0xt627NOeD12Ax0DUPDdJ4KjRv6fKWRNrc4v3T1oVeRkhheLdMN87hD1ywc2whyCcc+xwoqt13kDRcRA0ttuL8MYyYlUWEEhSXRj6DE2mk2Bf9fo312x7E6HHMPSKmJc5x+yDd406BePcVQzrBTjfqHFdhQ9R1FAJhUvAq2EPWwzkv2O4EYniUzsGFYgC33opcsHZ0pE1eYtq4ij0Ia9XxXu2wPUJSTJJ99/tHJvudZGcCYEoJmxSAdr85icN8IQ3tSD18k7cvs1NHzUZ1+hjMNxZojXTF4vxTCJ21mIgmqpkyzk4fPzLPkFPD3Xdno3VvEruaofUlGXU5/AbLtwVJilzmMCyeqipdO/CN4cy79tqcKaHVQYJtmpPBSYXASoO/HpmJai7iUJql5Ym6Ab2HR5WKeTTq11ZzCK9gt91KjUijE1qFAVuN2nh3cJJaVQGd6T8nBLGZf6emPNo0fs1cn3CbDZIxk23jxqYCPc7GGI79sMGyoFMvQmVsHaUu8xnXhmV3zEIyJtP7QrzBMQEDl89QTJKbsgr9set4Rnqt0P/Dg/1T4oV6yNkg/O3a+M4SH8H3avq+ylGo++Qp/LAJPKa0m9B5UgTzOFUPOqqgtKj4AmCAtS1a1wCTwI2qqE+YzgFled94f4031+49AiVxoimsP/3FhEAxsa+O3ZF60zwrfrFSvIiw9xwSU10pJKZlSifGsT9hrIjrikYH9qGUgQaW1ypg0WVAT44gYb89p3PWcNDu/Wl7uVNmjsPF1ZfcOa038tdzFPIRh5gMH3WZe410JjSWOS19+/Ss8yZcM3PHO1P29npfJvbogWeBGgBvlcVl51tr9P5HpWZMicnxg3O oIMy2dVS Mcbuu50UfT2IqWxOs+kqlzv4YMH2jMCiYNBKEskY4TPjX1D5STPWNYFWpdEyvg4xsCzXxvyWdSzskXC8kuMrNaYse/4jPu6gOkbl0Qo02UCB65+dhyla2grjRkJQX1MNjE2oh0hl+zqzccxar/3pOKzIaVw== 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 Wed, Mar 01, 2023 at 12:49:10PM +0800, Gao Xiang wrote: > > The only problem is that the readahead code doesn't tell the filesystem > > whether the request is sync or async. This should be a simple matter > > of adding a new 'bool async' to the readahead_control and then setting > > REQ_RAHEAD based on that, rather than on whether the request came in > > through readahead() or read_folio() (eg see mpage_readahead()). > > Great! In addition to that, just (somewhat) off topic, if we have a > "bool async" now, I think it will immediately have some users (such as > EROFS), since we'd like to do post-processing (such as decompression) > immediately in the same context with sync readahead (due to missing > pages) and leave it to another kworker for async readahead (I think > it's almost same for decryption and verification). > > So "bool async" is quite useful on my side if it could be possible > passed to fs side. I'd like to raise my hands to have it. That's a really interesting use-case; thanks for bringing it up. Ideally, we'd have the waiting task do the decompression/decryption/verification for proper accounting of CPU. Unfortunately, if the folio isn't uptodate, the task doesn't even hold a reference to the folio while it waits, so there's no way to wake the task and let it know that it has work to do. At least not at the moment ... let me think about that a bit (and if you see a way to do it, feel free to propose it)