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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11BFEC64ED6 for ; Wed, 1 Mar 2023 05:01:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229515AbjCAFBr (ORCPT ); Wed, 1 Mar 2023 00:01:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229544AbjCAFBr (ORCPT ); Wed, 1 Mar 2023 00:01:47 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 045A138B66; Tue, 28 Feb 2023 21:01:46 -0800 (PST) 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: Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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)