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 29CCDC64EC7 for ; Wed, 1 Mar 2023 04:40:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B340F6B0071; Tue, 28 Feb 2023 23:40:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE40E6B0072; Tue, 28 Feb 2023 23:40:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D2F46B0073; Tue, 28 Feb 2023 23:40:36 -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 8E03C6B0071 for ; Tue, 28 Feb 2023 23:40:36 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 60AEAC1089 for ; Wed, 1 Mar 2023 04:40:36 +0000 (UTC) X-FDA: 80519078472.26.E2E0AAD Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 3759F140006 for ; Wed, 1 Mar 2023 04:40:33 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=V7hSI29c; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677645634; 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=o7MbehWGYND6XLDZlBnJaQydm1QSl+nXiW5U9gE5KhQ=; b=z906xA0jqzci/0/sdg1Lre2SdCb1pGQId7Fhcc/XrGla++GzkQspvJJ2z4su67oyfnRzhC 715gdK8zrXVD1iorJk8NvCmislEmaG6MNCbWkhOl8uA3XnGMi3OLzAiPypDQhutQFJA43q I0UP0ZPLK00D8RnbEOI3EQnNuOy3o+U= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=V7hSI29c; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677645634; a=rsa-sha256; cv=none; b=3yI0CjloNm/3D5nw/4A3ZNUkOy2UXf1XolF+eN0soEqKr9gKvxQ5BIK0KgjMXlXeREs8xG Jk4bqk5KVKurTEma8vezGQFPW/pERp6u4o15NKwjg7r9J4+jRy3JJV58zHNhIOFVr1MRG3 UXYVr2S8BsGf5iNrPGaCqIzRreqzCWM= 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=o7MbehWGYND6XLDZlBnJaQydm1QSl+nXiW5U9gE5KhQ=; b=V7hSI29cVR99yN9mPyKRJ67eVM uBZXj407uSloZ7fQIZYAi+PosKZUFj5sgPoS7ERv2P6zLPe4qrKvEQulcqkNUosbnI0D/Ig+NzCMg ZIVvqIP4zkuyDm8r6n3bIFvH63+a7H4IEhrpJqvtvaEkq1C2GdES4KTNvmfZ3aeGtrVOeYU/dddgN XdKY00A5bn1YYOudmDCOCdgrutpC7SQdCPLtLtD2K22RdGjAhzohV7AHII+YFXj1EZyNBtuc+1ICe vA9eWaTJn4eg5Q6jCs4J54v/FR/8Aq7febgPU2hqUfKiWooBleQvlHOgDRZUsXtOQ7MN3ps3XGoUw Msi8jexw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pXEGP-001NX9-Kz; Wed, 01 Mar 2023 04:40:25 +0000 Date: Wed, 1 Mar 2023 04:40:25 +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: <7c111304-b56b-167f-bced-9e06e44241cd@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c111304-b56b-167f-bced-9e06e44241cd@linux.alibaba.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3759F140006 X-Stat-Signature: 5if3yq53gnxhb4cywyrrb9n9r1o3rddb X-HE-Tag: 1677645633-823404 X-HE-Meta: U2FsdGVkX19va2wAMKqXpfkUQx06linxhYaKO9f5LjRV5Sjg/icmzG236VSc0sxQubKnRjP3r+NHfgYD0R40uABRhpKB97wK7YFKIL3kTovRSPkwegfYiqGwyb+FaDuucnfDWog/I0jgA26RgfzxtBUTCvINLweQYIh6bcVCEuu3C8KOHnajJleNZsmGjCSbzaU5pjWPv5rLwucL5VdA1fBzU5TCmcbt7WRqJv7QxX19thLkhXiGWBfTOV6ETZh/0nykAftAIcjykuZ3BdIVMbdB5KO6QExM9IDrXjOCL23FZN5nidFtbUZhmvT5dFcOFUVaHf4TmGqRNKmbqvjwRGEkB4k513UNlOpFb9I+iHzAl7vfHLes/8Bg8KQTmEERgonR3vaMp02yUoy3IIFPppNRzU0CwPBOM5MsBiXecFB6ncOUgbev4T3byrku03Zg2PuxmZhbhNXcWMG2TrL2UwocaP6StO4uDM/PYLl2P9ts6TJx8jte6VPQZ1I/sGBsGTe0R2Q7H98puW9riXQPPwuy5PE6zg/zKGIXjNP4h4AtvWXaEWXjpV6uWXordkbGboiNmCUtmF3vwIlckHbOxTy4jUsjKpdgeyCtjw1pz8yf1R9+VH0GAhVOxQnau0HcCqGHuMS/e1Y8tHvG2Tw54AnhQ+7HGX5E9N5wqcFqZUTk/F/bdmtbMuxPbxkusikXA0bUbKDuX1dw/mFkMK/0kw5ZIcSRbZ5FNB1iaQLgdq/lgb9o5MpBPtrInpi6Doi2Tppu6QaXoruzZMQdIGT0Xn9P3ovs9WsmbtawO+Yj0lcgHP44Sb5ku9+q6e/smmrJUsGqgGZiN1aP9LaSVwXRa2QwsiXpiauOclHKE86FE0ovuTkzkv+ZfQMxGy0PkzxeqbEfiVeJSP74l1WqVhBgLSqCRoIS5rql4yZ1mS3TJtQ5S8bG0QejsAm/EZ22eP+UQcpuHIQsIYThIgr8ogP ki5RdHXB IHk/3n7dN0wtGYxUGhtRiE4oXgOMCFaiZTFwhKF29BiToc9NbSs9adlB41quSufcT7dRM1KiZmOYkRhoD/V8fmUQ+/NdxARuHRqa3rEsDHbGG55lvggk5B2Y4LHR3zvi9wpApMRyHnZ7LaC5OdoroQsN6FQ== 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:18:30PM +0800, Gao Xiang wrote: > > For example, most cloud storage devices are doing read-ahead to try to > > anticipate read requests from the VM. This can interfere with the > > read-ahead being done by the guest kernel. So being able to tell > > cloud storage device whether a particular read request is stemming > > from a read-ahead or not. At the moment, as Matthew Wilcox has > > pointed out, we currently use the read-ahead code path for synchronous > > buffered reads. So plumbing this information so it can passed through > > multiple levels of the mm, fs, and block layers will probably be > > needed. > > It seems that is also useful as well, yet if my understanding is correct, > it's somewhat unclear for me if we could do more and have a better form > compared with the current REQ_RAHEAD (currently REQ_RAHEAD use cases and > impacts are quite limited.) I'm pretty sure the Linux readahead algorithms could do with some serious tuning (as opposed to the hacks the Android device vendors are doing). Outside my current level of enthusiasm / knowledge, alas. And it's hard because while we no longer care about performance on floppies, we do care about performance from CompactFlash to 8GB/s NVMe drives. I had one person recently complain that 200Gbps ethernet was too slow for their storage, so there's a faster usecase to care about.