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 6827CC4345F for ; Sat, 4 May 2024 22:13:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F33736B0092; Sat, 4 May 2024 18:13:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE3BE6B0093; Sat, 4 May 2024 18:13:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAAFD6B0095; Sat, 4 May 2024 18:13:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BDD976B0092 for ; Sat, 4 May 2024 18:13:40 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3283A1202BB for ; Sat, 4 May 2024 22:13:40 +0000 (UTC) X-FDA: 82082116200.21.6BA28C4 Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by imf01.hostedemail.com (Postfix) with ESMTP id 67C4040009 for ; Sat, 4 May 2024 22:13:38 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FqjnwDvw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714860818; 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=A9unkjuVShUEk/iPiPG7EPoKRZdQZGGq2FXrz5dixV4=; b=gjIA2W6P8oie1En2IWOBPPt+jJx1jOJOsy+s1IGYKaErbb7CwQynV6cn/CLg58/lheXjJb FowMp9HmZq8NNWT/hmp/onIUDcVpniLiSr9Bu8I2yKOPMCktxv9i+839Qsl13KOs+PzMn7 tsWEipbnFDxZMDELL3I6JsstUyi+Mc0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714860818; a=rsa-sha256; cv=none; b=i0PbXhmBcwJ0fYCEQr0WVIolNJniUcTSVDMZy8CZ8Mqs0nDI27fpuRFMnqS5p6FCTKrHmh lc1aun8YDoT/n3s5tziFy1toLNcy2Nb8Q0ttE1rJS980dJievzzRMOwvkPOzD3OoP5Xm3O a9fkd+4q2+Te0rYB8dlvDV0FGO34Rj8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FqjnwDvw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-60585faa69fso461487a12.1 for ; Sat, 04 May 2024 15:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714860817; x=1715465617; 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=A9unkjuVShUEk/iPiPG7EPoKRZdQZGGq2FXrz5dixV4=; b=FqjnwDvwDCQPDBiwKdifWzsnfotts1JV4jhMUaiTVmOzWehRgQB9NjMowZoeoXIAPe NXOfyDQjc2pJ5rPZ7zGPkMaLBNIQ4MhXgqe76CiNX7XaAYa/XowKEENx4WEBvGx9DxCX NBwACd0DMimPxskUBF50qaMjTK6QzfFwemLPexOS7k39MrilAAzhH5CIwyWYELV8xICZ xbrDtMV6Sk3CHFSdUgzljTtkniQD0/GX0JZnmIIrRyWZFNYCdmB/3wpzfZyhEx8/eFsb U4mKhkmvJqTxYBrpqlDXWs98+tq0o7Q/uJSKR1M0tI7MpPBsewUrJajBNidc0gT87Xt/ cM7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714860817; x=1715465617; 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=A9unkjuVShUEk/iPiPG7EPoKRZdQZGGq2FXrz5dixV4=; b=qLkbZJvY6zdaLPiGqX4grN5Ehm7WPTiGlKaq1KpUuggv3ZcvOIuYNR+PDhzRkFoIgQ 869fO3pK/fvpnO3xZZV1V1nR5VoaV8gvlTRbDPL/HqkalPVY7f1gSLmx1LSqkKna9z4O w+YMDCOMTmdgyQzwnW4naVodd5iBRQ6kgBQf4Og9yb6X1jfpgL7r1Is7e5TDsesEbrjy 7QYb8kJspTeuY2Ajhl4Ym6vycjWQbFsRYvmYXxsELkg8J6hn4nbX98sJ3bfsOiXDJTvv BvfufMG0Gch15riiCC4r/LVbB34ydwVO7feehzeXOqBalg9807xuOphFjX7hdV6tB1Jx TVTQ== X-Forwarded-Encrypted: i=1; AJvYcCXSj+Er6mrP9RvOa1K9vE2a2iD+bwHLrwR2fcrFJk+DjocsXyYGPIWZUQjwFiW8uiVmTlTujKK/IAFPQAOb3cz8crE= X-Gm-Message-State: AOJu0YyGAGBfP6d5rs39XNfhhYBCnzWK3QKC7ZlIB7F9kJcV+80RTfev ZziHESLviqaLSGSWVW9+oaFE8zLMOeGSjhgqU4d29SKn3HwzejrRE1GKOJPRyvbcQBeVBhy3cRb jWhADJkPgpFA6duRluZQbbhAcLTM= X-Google-Smtp-Source: AGHT+IH7kyl9ysYQF/CgmoL9h1C0Cxvzu/JuyG42DgrFoEsKVBDHDDB9F2A7sEg1ahP0OclCgHXPLgibAOa4yjF3s7Q= X-Received: by 2002:a17:90a:d709:b0:2a5:be1a:6831 with SMTP id y9-20020a17090ad70900b002a5be1a6831mr14208459pju.19.1714860817143; Sat, 04 May 2024 15:13:37 -0700 (PDT) MIME-Version: 1.0 References: <20240504003006.3303334-1-andrii@kernel.org> <20240504003006.3303334-6-andrii@kernel.org> <2024050425-setting-enhance-3bcd@gregkh> In-Reply-To: <2024050425-setting-enhance-3bcd@gregkh> From: Andrii Nakryiko Date: Sat, 4 May 2024 15:13:25 -0700 Message-ID: Subject: Re: [PATCH 5/5] selftests/bpf: a simple benchmark tool for /proc//maps APIs To: Greg KH Cc: Andrii Nakryiko , linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 67C4040009 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: g7tq1bhzyda3c7xdtdmtx1dyw4ufumoh X-HE-Tag: 1714860818-232374 X-HE-Meta: U2FsdGVkX18WoCIx3gLvgXxJ9Ggq6Eu4Gh6Q5Yh2RWRDItWw9QvkCE0vlQnKp5R9MN0560dCwSJitZk7bTcm3GZ22JLBJDBBMrRmI4JbzkWMGqXFq0yBVJyKYFaqXcqdh3PEc6sD8VzykfowRGle9I7NPaCFJ1ElMierNH+KqM25yeSh7jQlLxG9WcHE6dcKC8voqHQhUYcBZt6sozvxlkPqsrK+eg7Pf1hznrSCpJp61SsWCS5MPBamGqlW9yC81hsP2A6zIaNP6gn+VcS/NZZ4duYNekUjQG2U2kL6Y+U2r/nHKzNKccIw1Ut8n0ONxRt4zezIrF5nZhcp0WD0ESDWMHt8arGm4siprwHQNmmQVkvKzpHEMPB88QJ0YErZ+EM7bxG1eQc+AlE6NKgxR7loMbBVE4jg5lDIirCMyOd+/qayc+9R9WsOlc6m803qYwwPMQDFb0ERoxXFHKusFwAL75gaEZ82EGKDyKl92vsAyeozxscnhBnTPPGyjszF3JHDjMBo6uVcvN0ry5I7oey7CGtZrKVAJ0s3Yk7R02WNHqP+cSAI9F0Qwyx7wQ9iyrD+zt1PYOL7Bx31gXvLOtodTTb+1sQrnICcbgRkttmftE7aQ1AdDHISDtERCtOfpF3WSliGC4+bD13+F69L2f1T3jENCWCYjRvmKNDCfsgvI5XrssjrIUP1mB2MqAkni+NhxGP1zGkTBTbgVZAZBX8kpZCxpRtKa54Lq7gcCmgefJz/OnI40LMvfIJKeNeoId4TOlFGv29PQ2eHT4wezwnjZ/4h16LUg1A0Iu6qxTqdU4NCOrx523jC0uFJC59uy6HFoubC8+tSo7Rd7tvo6GWFpmoJpWqP5grx+nnlNaBRh6tzwC8vFYUIemMYajpIZ3Q8fcs6XMXJZgTXI8ToYZJMeNDK9lEEC1sFxyRizXF7Of6ncclrv8IKu6yJhIfL9sXRlLwU/qztI1Ymhbo lVk40k0s jjh9Pb5gySrDNLtcuQrMIblMyBgCJ7+JfRRUvf3ALa4JiAuyhfHtIYrxQQSAct7SJJDWfrLZe3nXDjAiI+p17CZ/m4PCQzYTPQfm6wDKTZ0aWWwPJ190Me25XfKTbK3TNGEHpHLlsYAsxpPoMSg3Td2WCfrNVHvoA3QQv0aFjG3VzrO2akRqkpdQYSkz2Tz3wGk7yrPYDt/mwvNK0xcu+RLMPCM85NYqfmOGU6lX/SwpoN+vv5/8jrsEQwRBN5zeV9F8Pc6adKHmLhwAPCoOhpnUiD/Hm0s8ExHYrWo6cIsAsIGoXTpJLKchjPRmgyC/OjqBb1uiO1zc7pFvMghg/hFRpUjzDlteacuOpTs93jrjg+d5t3mxswQl/Z+rR9HjnMNMTT/oZ4yQLajRqBAyyyajvSA0tFHuA3PBcMqrTurNayUbroG+cuyTvSqj/fGX9iDPz 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: On Sat, May 4, 2024 at 8:32=E2=80=AFAM Greg KH = wrote: > > On Fri, May 03, 2024 at 05:30:06PM -0700, Andrii Nakryiko wrote: > > I also did an strace run of both cases. In text-based one the tool did > > 68 read() syscalls, fetching up to 4KB of data in one go. > > Why not fetch more at once? > I didn't expect to be interrogated so much on the performance of the text parsing front, sorry. :) You can probably tune this, but where is the reasonable limit? 64KB? 256KB? 1MB? See below for some more production numbers. > And I have a fun 'readfile()' syscall implementation around here that > needs justification to get merged (I try so every other year or so) that > can do the open/read/close loop in one call, with the buffer size set by > userspace if you really are saying this is a "hot path" that needs that > kind of speedup. But in the end, io_uring usually is the proper api for > that instead, why not use that here instead of slow open/read/close if > you care about speed? > I'm not sure what I need to say here. I'm sure it will be useful, but as I already explained, it's not about the text file or not, it's about having to read too much information that's completely irrelevant. Again, see below for another data point. > > In comparison, > > ioctl-based implementation had to do only 6 ioctl() calls to fetch all > > relevant VMAs. > > > > It is projected that savings from processing big production application= s > > would only widen the gap in favor of binary-based querying ioctl API, a= s > > bigger applications will tend to have even more non-executable VMA > > mappings relative to executable ones. > > Define "bigger applications" please. Is this some "large database > company workload" type of thing, or something else? I don't have a definition. But I had in mind, as one example, an ads-serving service we use internally (it's a pretty large application by pretty much any metric you can come up with). I just randomly picked one of the production hosts, found one instance of that service, and looked at its /proc//maps file. Hopefully it will satisfy your need for specifics. # cat /proc/1126243/maps | wc -c 1570178 # cat /proc/1126243/maps | wc -l 28875 # cat /proc/1126243/maps | grep ' ..x. ' | wc -l 7347 You can see that maps file itself is about 1.5MB of text (which means single-shot reading of its entire contents is a bit unrealistic, though, sure, why not). The process contains 28875 VMAs, out of which only 7347 are executable. This means if we were to profile this process (and normally we profile entire system, so it's almost never single /proc//maps file that needs to be open and processed), we'd need *at most* (absolute worst case!) 7347/28875 =3D 25.5% of entries. In reality, most code will be concentrated in a much smaller number of executable VMAs, of course. But no, I don't have specific numbers at hand, sorry. It matters less whether it's text or binary (though binary undoubtedly will be faster, it's strange to even argue about this), it's the ability to fetch only relevant VMAs that is the point here. > > thanks, > > greg k-h