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 0D5B6C41513 for ; Wed, 16 Aug 2023 09:50:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98E73280002; Wed, 16 Aug 2023 05:50:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93FCD8D0001; Wed, 16 Aug 2023 05:50:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80808280002; Wed, 16 Aug 2023 05:50:23 -0400 (EDT) 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 6E5AD8D0001 for ; Wed, 16 Aug 2023 05:50:23 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 49B60B2406 for ; Wed, 16 Aug 2023 09:50:23 +0000 (UTC) X-FDA: 81129497526.25.F75C2C7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 51DDD1C001C for ; Wed, 16 Aug 2023 09:50:21 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IqJdkMM5; spf=pass (imf20.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=1692179421; 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=EeY22uFbxE9bAvt1E0mE8TPPOJ4pLMU6pIYR19wlTvg=; b=2RVt6o+Ohm+SWlRc/ANFcmDgDu1eEphRf43q/8nu+OL/GOE0lQtzF7kBXFwHGqhtK2GpAm mnwLqZdu1Ak9kUsDbYUV0SIGaOk8IYpOvACFqp/ReEvxE2PXEobjW+i2Mm/84WHoabUEXi t3spY63RglyjZI5Ojg/0HeBYzHD7YFY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692179421; a=rsa-sha256; cv=none; b=UOSDZ8CBUKx8THo+tmrcXrLwvp88JopniNo9yHyydCL+CiLOqN9fK6S8x7iMUM0wl/dReu UKGKdwhSpcNXSyZRY1F11vOmRb/sVWsMsZOzFqI/lC2Cvfaaiu9sIXDdgJ33KM1vPM3Sn6 sPLa5jzqTwqozf3LLB0C3Bs1TIj33Nc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IqJdkMM5; spf=pass (imf20.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=1692179420; 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: in-reply-to:in-reply-to:references:references; bh=EeY22uFbxE9bAvt1E0mE8TPPOJ4pLMU6pIYR19wlTvg=; b=IqJdkMM5N7pjz97aHX5sadr1jwDRfkIAUvCIupIZ1RH1YoT9xVtReIgLphycmlsKz9bUSb Tc1uRaziTMesKhxI2my/a3BZDKf3NCIWKuNlpZhtC/cEdxyqiA0yN1hMkRY6nQOH82KFAI LkWtKewGJx1gTMHwILvX3rbBnfLnMgc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-14-u8i2T3oZNvOAN8VauQwTOw-1; Wed, 16 Aug 2023 05:50:15 -0400 X-MC-Unique: u8i2T3oZNvOAN8VauQwTOw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 632D5800159; Wed, 16 Aug 2023 09:50:14 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E52840C207A; Wed, 16 Aug 2023 09:50:11 +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 In-Reply-To: <8722207799c342e780e1162a983dc48b@AcuMS.aculab.com> References: <8722207799c342e780e1162a983dc48b@AcuMS.aculab.com> <855.1692047347@warthog.procyon.org.uk> <5247.1692049208@warthog.procyon.org.uk> To: David Laight Cc: dhowells@redhat.com, Linus Torvalds , Alexander Viro , Jens Axboe , Christoph Hellwig , Christian Brauner , Matthew Wilcox , "jlayton@kernel.org" , "linux-block@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH v2] iov_iter: Convert iterate*() to inline funcs MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <440140.1692179410.1@warthog.procyon.org.uk> Date: Wed, 16 Aug 2023 10:50:10 +0100 Message-ID: <440141.1692179410@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Rspamd-Queue-Id: 51DDD1C001C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ktazt56f63g9ke6nba4dpt58rnmpb1f7 X-HE-Tag: 1692179421-578214 X-HE-Meta: U2FsdGVkX1+jC4WYuRcBOm4sE66DMrpUh9kp0U0k7Znld9lbB/sdxVBSX0nVKXXDJZuFisC+H5oRBuZ5BR3qdCdpdP3C8PT0DMqGTnmCmYiHo2hiFcRJjC8143jFxJ2r1rdTU2mVuIITDM2KQpt0TquNeIuadwcla8gwMj07EJOkjn060eEaP9iuqbQyUREcQxE+bqbixbiL5XIl4EqGDFplniPRtDt/din8xUHSgfaQs7dglOko6qoPfpaLTHEWKp6a7czyS19Olnw5zr2wN0j3cib2VinMVHYkxnoQu9krf1HV/CjEF+7G5Vr1b359V9WWs5+KMJfLMB2duvVfn7PeWdLh+rNGY1dMIKk2NBl2qhs863DuhtfInqe/8+4vQ8vw3jc4WtJBgMQ5gDU8gvs05UlJqyh01hgsxSE7NDOGAn0pDxUNvrgqnB2CIm7QQZZf+7jIsvPItQqc3orAO7WJk6lAQshOXKVwvKJuKQp143yGZ2j7WfoYyY/SVXJ+OL7j2fJ1U1c0OIJN+hLUVW0itKnIaaWaINFJDKxA0UifOYyk3I9O7PzZN/18d4jjbdMqW/VB9V5DPfp3Jdn8VrCFCMGCRt9zC3xW9nO2Lse0H2lMpU1W4ykbSyFjYb2NxjdY0Z6Luq6FBKaRM1J/m+9sJsaYmiVgdO4wJRXt/HlxYrU2dyiW+OBWmIm7A5+0/w9GdIaMelVWLdv3ZBXirYw6CwYiqQjnVFqS04g4SACG5Lvrcy84Vu3ZvAKKFs8yxiotyz51zkH/ZyXG8PtfcVfHqqfNDL4omEhVFL7Yj9QkQkV3aN8GsCJfUbPuj9ac+9pZE7IHY0p+94Bev3qzWaL5IDw+bXLBlrtdI9CEJ+6cM2P4CShSyhQykDDryzMqScWfwbnLudCCgr1QJg3bWz++ooD5wtE7BxK35mUJNBYwFtLjNrbXASFUjzf7gYGEpdCFD85FrLs8DbqgPv0 V1uPrs/M bxmgsHBISFDjJikW9OPDUlpCLm1zceQW8fKzON1GPLTbWguDJGGVEObqUcojtHx1x36ivoLimC9t3+OgqXygTc86UwntYTmsskiGhLxs29ByXOzpe6ZeRgnG7zvROSF5mxgZzB70pyrt5ZrWD70fFAVAVv+qtbWTyLnA7qcRPNiC4nM0mH1gX5tpXSJIGbGRcYuNN/WY9cvopZMGt2xFd1dZYbFk87EkS7+kbHu2XZwYnhD9u/qkpqUTEWym9HB60PHgKbpYWUC7UdGKZT9BSOFzu54PwNHBo4BpPuJlys9ZUq0E= 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: David Laight wrote: > It is harder to compare because of some of the random name changes. I wouldn't say 'random' exactly, but if you prefer, some of the name changing can be split out into a separate patch. The macros are kind of the worst since they picked up variable names from the callers. > The version of the source I found seems to pass priv2 to functions > that don't use it? That can't be avoided if I convert everything to inline functions and function pointers - but the optimiser can get rid of it where it can inline the step function. I tried passing the iterator to the step functions instead, but that just made things bigger. memcpy_from_iter_mc() is interesting to deal with. I would prefer to deal with it in the caller so we only do the check once, but that might mean duplicating the caller. Actually, ->copy_mc is only set in once place, dump_emit_page() in coredump.c, and only on a bvec iterator, so I could probably do a special function just for that that calls iterate_bvec() rather than iterate_and_advance2() and then make _copy_from_iter() just use memcpy_from_iter() and get rid of iov_iter::copy_mc entirely. > Since the functions aren't inlined you get the cost of passing > the parameters. > This seems to affect the common cases. Actually, in v2, the action functions for common cases are marked __always_inline and do get fully inlined and the code in some paths actually ends up slightly smaller. > Is that all left over from a version that passed function pointers > (with the hope they'd be inlined?). > Just directly inlining the simple copies should help. I did that in v2 for things like memcpy_to_iter() and memcpy_from_iter(). > I rather hope the should_fail_usercopy() and instrument_copy_xxx() > calls are usually either absent or, at most, nops. Okay - it's probably worth marking those too, then. > This all seems to have a lot fewer options than last time I looked. I'm not sure what you mean by 'a lot fewer options'? > Is it worth optimising the KVEC case with a single buffer? You mean an equivalent of UBUF? Maybe. There are probably a whole bunch of netfs places that do single-kvec writes, though I'm trying to convert these over to bvec arrays, combining them with their data, and MSG_SPLICE_PAGES. David