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 34C0CC369CA for ; Wed, 16 Apr 2025 22:30:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BD91280027; Wed, 16 Apr 2025 18:30:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 06C4F280024; Wed, 16 Apr 2025 18:30:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E75C6280027; Wed, 16 Apr 2025 18:30:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C38A4280024 for ; Wed, 16 Apr 2025 18:30:29 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D2623140E66 for ; Wed, 16 Apr 2025 22:30:30 +0000 (UTC) X-FDA: 83341352220.01.17D2EF7 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf27.hostedemail.com (Postfix) with ESMTP id EA50D40010 for ; Wed, 16 Apr 2025 22:30:27 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=Z9wB67ka; spf=pass (imf27.hostedemail.com: domain of csander@purestorage.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=csander@purestorage.com; dmarc=pass (policy=reject) header.from=purestorage.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744842629; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XfRJOJ9CRsHZJefMhleN5QEhzGV0ETX7MtMvPUoW28c=; b=yGsX9Ux0gjNxvvwqBXfkh0gThgTAmLEeWJMdcHzm+5QRjd/dOBmGhKaglEY9U41rryoThv UTcVAGpu9hZqQObq62mf5ZePGgHD8OWYtZXGLHJdFeC4ryCyeSwEYi6kYctIw6T7UwPezI wO4q+RtB5zwVBKXqhUbWtQnzoIyqU0c= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=Z9wB67ka; spf=pass (imf27.hostedemail.com: domain of csander@purestorage.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=csander@purestorage.com; dmarc=pass (policy=reject) header.from=purestorage.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744842629; a=rsa-sha256; cv=none; b=TtoKu+yXrcR3mS+r3uEuIJ13u3SbVNq9NzijnOkGebVOXynyITlXrkhmj8NPhK2dDV0lwL 9FJSDDELMZk2y6U+BAif6JDoeAQIAKCKG7C1d0uP5CdLcPooFTw9a7OuIU9zCnicwIxoip oRSefc9Y69PGmwzhoMkfAHZDt7oFLIk= Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2241c95619eso387335ad.0 for ; Wed, 16 Apr 2025 15:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1744842627; x=1745447427; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XfRJOJ9CRsHZJefMhleN5QEhzGV0ETX7MtMvPUoW28c=; b=Z9wB67kaskR0+UJXV5AwFl6HnkE1eRio23eUIaNBrrCBHLqW1A88h1sXdI+x9s9uyd D08Pt20MS6MkySlfNcTnS5Tt575W7Bs6iPUl5buGt5OCRcPRqPC5w4VfLo+y55VEWUad kx1yZxf3mky8vGCr2vNGUX3iLqiLQyagbK9JUeyZvtVkGYNnBNb3lvkLk0TXAKXGI9yj meJNapv3NN+TfSVAkeNNY3gi11NUhSrRJxV6kIeqoxMicjZ1JABL29gF0N1lO2YfqAE6 LchuJCzyUT2AYXClLO7ATjq4o5m32qAadnR8WYIHcwaB8r/lwADcwUtmThfpJLVzetHD 9Kpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744842627; x=1745447427; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XfRJOJ9CRsHZJefMhleN5QEhzGV0ETX7MtMvPUoW28c=; b=ZICqYaZ4vovly65KHWD2iGWlcitztMN+i67Z2x07yUx1J70EqS3HTKilgW+xUcExnY f6aT0wBAXJUDZYx0WO2F9yjiHATJy87OhIynNq2c7bfKlsqpOSjeIEFyStL7eRMHCblt 4ZNIB6VcdyBhF1Aifos0DwMedj/ZRR3AZXRA2SdpUpx4pfRl25ChQOAWWi/bJBwvCM6s 7FowkgPoKvAwbar454Ms01ErCd4ccymO2wWqrR8f+ukPBX+wIFXREeqxiI2MNRfNboe6 oD85IxHraiBcZShPapJATXgsE9RxfutFk6a9vj6Ydi7DXIBs5nl3R3H566jcOH4GnQVd p/lg== X-Gm-Message-State: AOJu0YwJXEwID2VG3D4Ui/pf9BNqH0NS342OfnKU0fUx+mShDuDoSz8H O7+ealgvpnohTZ1k8wDEUzV62yroS2m/ggyuoSrtePqwbI6q/5Eiw2qJr52NmzG/Pk6GgIHCoNp JtATYGcWfX4zHDE5U4tBUHuGhE94We710vSN+dA== X-Gm-Gg: ASbGnctzWgzKwBWiTSaZEKqJiT8c5zW4HKb1HfRigmfK/rwpsjbm8Fh9sbE92mh7dKJ PZ56cG1T1UfNs9OmvivveF7yONROATQG90W4df8VDjD/47+KDvNV16Wb5/Laes4dv9L8tfWalqp Ln0AqRrMXm/T3JILEtmRmn4HEk X-Google-Smtp-Source: AGHT+IFPCjiCP4UFzZ0MkuOGd+hSWcQBivXnxmbuOQEvtCyO5XP28tMDmUgVwNQMpakN6HjgMHswlg1t+ZtZyAQy8wk= X-Received: by 2002:a17:90b:3ece:b0:2ff:5540:bb48 with SMTP id 98e67ed59e1d1-3086d477001mr818376a91.8.1744842626698; Wed, 16 Apr 2025 15:30:26 -0700 (PDT) MIME-Version: 1.0 References: <20250416160615.3571958-1-csander@purestorage.com> <20250416150529.1e24677e3798cd783f4adb8f@linux-foundation.org> In-Reply-To: <20250416150529.1e24677e3798cd783f4adb8f@linux-foundation.org> From: Caleb Sander Mateos Date: Wed, 16 Apr 2025 15:30:15 -0700 X-Gm-Features: ATxdqUFBl5hBWIF_oWQiK-ZiCgPwok2zNFOKH2CPgKufEkvUGI0fDCz9XU9nTSs Message-ID: Subject: Re: [PATCH] scatterlist: inline sg_next() To: Andrew Morton Cc: linux-mm@kvack.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Biggers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: p3isxaieyyqb5wq4dk5thu58sxutq8ud X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: EA50D40010 X-Rspam-User: X-HE-Tag: 1744842627-253140 X-HE-Meta: U2FsdGVkX198qdEZQH1/hN3xGKQ0vFEIgMt5KllBpyDdlPhV195tomRuDk26w8jrAR9N6tTefa8sr3Pm9ylOniLrB/cwaCHeMab7lX9ZClWm5D9JuMTZaD4zYuTXlaG9Qe1dgh2EddsAF62b6Z/A4LW6YypBc0tlicl/FcV9zGgAw54hla4sQY8gGslu08nSIM3fNTWCstytbZosR3sc8IaddCDku93jMa2gUs7TYZ4NcQsNlhsdjuXUx72AyN5/TgREY2WWVBIEh4o34WXGLR8R/BVV74Pk720fiPZZAedcIZ3e+RoDZjFnquX26vn2NEVJDVfplY3I5Y7CKIjp+btT36VRYRT6d4wDmU11aj/Fn9GZCh2Igmf1VpHdmm+f4HxW/OiSorHpTnxzvK4uZHTe97fGfG+ppV91bfjUOY8A35DcXZZLDpkUuXzd4vSvKxKLiPa2lOH9BGkwkNf1KWDASSZN3/KEnPUBbn4MhU9oBXqDmUSPllVgWWeHvenSbl8O6V/XWztZasjNNTqLTVpVYdW+2SkHE7ouXspsx3c7grF1r1RbW8nZO+2lJrm+RtbQ6tm9H548Sk+GtAvCNZbCMODpoIJF+1HjRzzhzJyYk5KZHhs92X1IkWocW15rqEahXBxpuVYs7bmWDMXeGqS+ZC3ORElO78Ko6uN/xGHM+L7BW3yI6HcVgHVHzQtphJArIIeASveEBa4E+qLtVehSfP5u7k/ICoiZq7+IBKlSJQaeVI07RYjE3Qbnlow7n/L7x8Vp5iD6zAVJlSZ7b2XJi7GU4ST2DYCn2WdEQpM1Wxx5lnj/YaXlWbHf7Vj1HIdgZZOg4Tp9ngHGRKpd6PcVi5TLvRM8Ni0UDCHGqYKf/kU2WfbKMi4ANruSYyMRqKWdLmsbn8+mrbHzOeQYQAhiPzt//HVcdc57D4wP5gxEDIWZGFsjCcyzWiitPCOZNHEW861q2gs7TU0yPzQ F5KCP3P0 fU8IRAkahbpvn52irXjNRTcscS8BdYWwyq0U69p+L9wChEkJQTjceMEjnhZJjYDzDypi1nwT31rwJObzSaSad5MG55hfIIX7uKAwhYrQ/34QmLw355m50lP2qvJiYXHTkEhXKD7zBNVr42Ve/dN0o8zQbc4y7R3ksR8qxatVaExikdtuAKnd0ZkO+HqmOgH7jf1NIEt6DjVgBdP1IcpHo7krZRmy5gpoG++D+ICiel0qXbTCG+4tei/OCUuumZACqU5FFqI60K4G1ASCOeSkhx272sHPfk9LtYPoijphE+TPEKoqtyIrhmBNnglFOHgWs+1M3IF2CS4J/E9IdFifTzL2gzNvR21zCh0bjtgbD16bYVn73MSNvf7/NSF0AqCIrKLUt X-Bogosity: Ham, tests=bogofilter, spamicity=0.089934, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Apr 16, 2025 at 3:05=E2=80=AFPM Andrew Morton wrote: > > On Wed, 16 Apr 2025 10:06:13 -0600 Caleb Sander Mateos wrote: > > > sg_next() is a short function called frequently in I/O paths. Define it > > in the header file so it can be inlined into its callers. > > Does this actually make anything faster? > > net/ceph/messenger_v2.c has four calls to sg_next(). x86_64 defconfig: Hmm, I count 7 calls in the source code. And that excludes possible functions defined in included header files that also call sg_next(). And the functions which call sg_next() could themselves be inlined, resulting in even more calls. The object file looks to have 7 calls to sg_next(): $ readelf -r net/ceph/messenger_v2.o | grep -c sg_next 7 > > x1:/usr/src/25> size net/ceph/messenger_v2.o > text data bss dec hex filename > 31486 2212 0 33698 83a2 net/ceph/messenger_v2.o > > after: > > 31742 2212 0 33954 84a2 net/ceph/messenger_v2.o > > More text means more cache misses. Possibly the patch slows things down?= ? Yes, it's true that inlining doesn't necessarily improve performance. For reference, the workload I am looking at is issuing 32 KB NVMe reads, which results in calling sg_next() from nvme_pci_setup_prps(). About 0.5% of the CPU time is spent in sg_next() itself (not counting the cost of calling into it). Inlining the function could help save the cost of the call + return, as well as improve branch prediction rates for the if (sg_is_last(sg)) check by creating a separate copy of the branch in each caller. My guess is that most workloads (like mine) don't call sg_next() from all that many places. So even though inlining would duplicate the code into all callers, not all the callers are hot. The number of locations actually loaded into the instruction cache are likely to be relatively few, so the increase in cached instructions wouldn't be as steep as the text size suggests. That's all to say: the costs and benefits are workload-dependent. And in all likelihood, they will be pretty small either way. Best, Caleb