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 B8B1EC02183 for ; Fri, 17 Jan 2025 21:17:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 068C26B007B; Fri, 17 Jan 2025 16:17:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 019206B0082; Fri, 17 Jan 2025 16:17:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E22686B0083; Fri, 17 Jan 2025 16:17:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C34E36B007B for ; Fri, 17 Jan 2025 16:17:05 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 525C9160EB7 for ; Fri, 17 Jan 2025 21:17:05 +0000 (UTC) X-FDA: 83018204010.06.C417027 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 6135A180007 for ; Fri, 17 Jan 2025 21:17:03 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FBnDzaCl; spf=pass (imf16.hostedemail.com: domain of dhowells@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737148623; 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: references:dkim-signature; bh=Ua0SGNyvuT1kxIzy+RNpyrvAiXO1J40KcJJ7nVEy62M=; b=n9t7xRbJK66Phazo/DiK0lLC4KVYeAa+UZruenOLf2puIRhbHg/Vp58lfS3GqiUVs8gqof idcaX2Lp+1gcZf+jMDSQKsR+KFmClBrV7ls7Om9RKS1O7/asDcKVIsnaXk/fN0tqdZtAnm t1lqJV/T9qEZ+mfSGnqrzKV/3TXIVEc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737148623; a=rsa-sha256; cv=none; b=fDZP++vbaMlKLKj5W9ziHO5PoujvtRLEtwnEPiWdprhrNHvuIjo2yfTtsE44+gVNSMB5WC OYNYRRpT62gNexwE87Qi7QgldG7f6pZjmyhPfbDNVu72+nuFO96gChtvHP1qUlj385bB9N oDBUPGRMa3oPzalpUjlHS8lmdD6SU2I= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FBnDzaCl; spf=pass (imf16.hostedemail.com: domain of dhowells@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737148622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Ua0SGNyvuT1kxIzy+RNpyrvAiXO1J40KcJJ7nVEy62M=; b=FBnDzaCly7/qcepkXR+paditHrNO/rwuawypZ9hLfwGF8i0pRRvkRTTM7KltRMHOs//YfT VLOFV2wP9/CfoFAbMI+33JxUlapshQT75ztExAN7OtpObzEboDrUd89DP0THL/FOhHsiAh hGIfsMRCkijUhRLZvDyinFLRrtuu+No= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-660-qpBZ4n8tNsygLAgiGWDXSw-1; Fri, 17 Jan 2025 16:16:59 -0500 X-MC-Unique: qpBZ4n8tNsygLAgiGWDXSw-1 X-Mimecast-MFC-AGG-ID: qpBZ4n8tNsygLAgiGWDXSw Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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 mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 49CCA195608A; Fri, 17 Jan 2025 21:16:57 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.5]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E786719560BF; Fri, 17 Jan 2025 21:16:53 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells To: lsf-pc@lists.linux-foundation.org, John Hubbard , Matthew Wilcox cc: dhowells@redhat.com, brauner@kernel.org, Herbert Xu , linux-fsdevel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org Subject: [LSF/MM/BPF TOPIC] Improving iov_iter - and replacing scatterlists MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <886958.1737148612.1@warthog.procyon.org.uk> Date: Fri, 17 Jan 2025 21:16:52 +0000 Message-ID: <886959.1737148612@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Stat-Signature: 8s9zn9tmzruearmoxhc7c1megmcihbr8 X-Rspam-User: X-Rspamd-Queue-Id: 6135A180007 X-Rspamd-Server: rspam03 X-HE-Tag: 1737148623-464814 X-HE-Meta: U2FsdGVkX19k4vSujiKz+pWXurRD3RQcv7mZ4CszmHDpgrN4ze5ihPX5eIGhJ0DX8Odj+vWt/8+oC0FFi8/+Gf4xQp2GbQx2TMHWA3+WdeKyHMogR/ydwNDit4/x2dxlePoC23TPiO/rQiwsGhFP098xBM7IH2hAmGeNU6OsURhPMZMDsxrj1oWRUCySI5WBbwPhrGxF8rRKfVN0bdWhz/7O2Kp64X403LrHHYXOgIAR3n5aIySCoWrEexVehNetE3lzwZpb26epJDHBMDItJWt20cI2JuIn87i/1wRJjGPq3SUDsmpmwBrMw4XQduaHwRWDvP4+IWcH7EPi86YUsmgvrx1CBvmX7imMJdEBAgkPDenTe4E7k4Rq8dxGgDNJCpUuKzOYpd76dWpEmG/sIvRio4BtvAhIa+cu5vklNdJpQRDbmV9G1GKA2TICWy8Uujo3r6tdwNPw33v5xxHwQbCqWE23D1LMRdq2qGfXaeRpyYl9geFLd2oBylwdbmNml1WpSy503cf5152lCon0dP8FShmIref+MzzoySUSJFhaBWzcp722u6fMXNCBQV27+50Z09Ad+2WT/xha3tydhRpcknfxxBPn872LaK7c9rwsG3ai8p+fK8FvKjsvWtvI6fN9k/IXMlCQwJ604SLPL6eS3xbGdLZIwukz4KXoH1o4F5cwI/JrP4auzNkREI3jJtmz2BPf8mzDGT+2Gu4aYkCxdpa0J/xtOHS9w/JDyVxEaiGq+QOAY9Jt/oQVlg6gAFVpez+LpX1ueNTXPMZa9+1fBI53RmyiPfdI7Ii1vgpMXGZHC1hPWt5l/vfYhJqmhXosr4GKwBJ3Jiszs8ykL9yzBliJjOXcy8Az+ju3mlejyL3s82v0BIsrKMYys5He75MC4U0JUotB+vfcWmmEeTnbLQmdGXTkp05oB0QDMTl3ymHgHiMWcaVHZZBq8PPXbkcucjYTJVQnoFY8oM1 vFXxE1BM lJPaoHTIpGceNGNVhjG9Q9Ox/DOn3K6xa6sqt6upXJA1BTwSjdxUKhusB7yGEdog0JIGI8+V0AAm8vHZaw2+suXCQNx0b++6JL2DkrxNNc48+JvD9P7E2vGz4g42duMdJBQ3qQn8A84IKs1Sf11GefPd1AQcTWu9ZS9JWD9Cn2RgZcYtW3U+flsvw+a06mbBH8Yr+jBLGqffHyW2m123tjFgUMduj7Ppv6AtTsN82Hdt6SBYqiLNE7SDrJzKKS5M25U/NpSnqyy3YbQzRgGgx3gzl1iPqGn/VAw/V3uN5p43RiTYu7Bm40fl36QZIOmCmiGcgrMBe5gVEb1gZNU32l52he09Z2OIgtvrE 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: List-Subscribe: List-Unsubscribe: Hi, I'd like to propose a discussion of two things: firstly, how might we improve iov_iter and, secondly, would it be possible to replace scatterlists. [*] First: Improvements to iov_iter. I'm trying to get rid of ITER_XARRAY; xarrays are too unstable (in the sense that their contents can shift under you). I'm trying to replace that with ITER_FOLIOQ instead. This is a segmented list of folios - so it can only hold folios, but has infinite capacity. How easy would it be to extend this to be able to handle some other types of page, such as anon pages or stuff that's been spliced out of network receive buffers? Would it make sense to be able to have a chain of disparate types of object? Say a couple of kmalloc'd buffers, followed by a number of folios, followed by another kmalloc'd buffer and mark them such we know which ones can be DMA'd and which ones must be copied. Currently, the core iteration functions in linux/iov_iter.h each handle a specific type of iterable. I wonder how much performance difference it would make to have each item in a list have its own type. Now, I know, "try it and see" is a valid suggestion here. Rumour has it that John Hubbard may be working along similar lines, possibly just in the area of bio_vecs and ITER_BVEC. [*] Second: Can we replace the uses of scatterlist with iov_iter and reduce the number of iterator classes we have? One reason I'd like to do this is we have iov_iter at user end of the I/O stack, and it percolates down to various depths. For network filesystems, for example, the socket API takes iov_iters, so we want to plumb iov_iters all the way down if we can - and have the filesystem know at little as possible about folios and pages if we can manage it. However, one thing that particularly stands out for me is that network filesystems often want to use the crypto API - and that means allocating and constructing a scatterlist to talk to the crypto API. Having spent some time looking at crypto API, in most places iteration functions are used that mean that changing to use an iov_iter might not be so hard. That said, one thing that is made use of occasionally with scatterlists is the ability to chain something on the front. That's significantly harder to do with iov_iter. That that said, one reason it's hard to modify the list attached to an iterator is that we allow iterators to be rewound, using state stored in the list to go backwards. I wonder if it might be possible to get rid of iov_iter_revert() and use iterator copying instead. David