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 3F778C4345F for ; Sun, 5 May 2024 05:09:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CDF26B007B; Sun, 5 May 2024 01:09:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87E086B0082; Sun, 5 May 2024 01:09:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7458E6B0085; Sun, 5 May 2024 01:09:54 -0400 (EDT) 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 53F546B007B for ; Sun, 5 May 2024 01:09:54 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C993EA0532 for ; Sun, 5 May 2024 05:09:53 +0000 (UTC) X-FDA: 82083165066.03.A4EE0D3 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf09.hostedemail.com (Postfix) with ESMTP id 071FD140006 for ; Sun, 5 May 2024 05:09:51 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qI0QlXRr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of irogers@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=irogers@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714885792; 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=+LFEOHbhdT8xlmXAZ79el6d0XvgZNSArYbb5H09rUb4=; b=ZBiIw4F+cWuv6eh1NFcRa6hpgi+c+OTIpzaBkIrsLrN9J5bZIA5jm5u3DD/KUhTwPIz9QP otPbghQ8wG6AJ4oy7728QGucSU66O4jxOJEReRcv098v97+cBspMt9UgcRLV+IQVvEnipS hPEUBfUneGSSi9+t3nk/BFgeed3MhxM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qI0QlXRr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of irogers@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=irogers@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714885792; a=rsa-sha256; cv=none; b=H0wGq+uxwu1NsPAnGsDNBMrciwYvNSt7sPEOejXph9VrdLLXrnpZsKPrhdqDsGiY0QTvd3 JxdeZSe9HIfXGkFF0uLFBIBLlDbDG+G7IKXu6bNUxA8LE6cKEIeTdb2TuCu55hcfuFoLZj B38NW9FZHfzPktavQi/JBpSxn7sCMkM= Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-1ec76185cb3so128245ad.0 for ; Sat, 04 May 2024 22:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1714885791; x=1715490591; 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=+LFEOHbhdT8xlmXAZ79el6d0XvgZNSArYbb5H09rUb4=; b=qI0QlXRr5OsALFBNfr3CaWJN7ZosGWV657jqZ2FmkWxu1n8QvnWenK53Tqiojz/tF/ bN7anl/MKn2ViI4mo9BmoOxl3YipN5h3XwfR7pd2X2YongQWtoLYVJLMVvWVP5UlDFWw z22NgSMV4QCL+tqzoJna16nBCuth+7czDubsGSuYV/Mcz+s0wtB6c4Zf9CEkCa2+erJL cIJDx8knpuRTUwzV8LkYQSOF42Kov0R7baxQOLflKR+HprU2c4Nay/ZzhCbiYthu85ox 7W6S6ObXfU/j/vmKKtIdADqCPnWdDyoNLHnphsw7j4GxZPUl9k0sJ35sVMlv4Poo8Y9q wBKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714885791; x=1715490591; 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=+LFEOHbhdT8xlmXAZ79el6d0XvgZNSArYbb5H09rUb4=; b=D7cVPumcsP7F+joN/K23ZH7tI9IJyPKXnR9ZWQxs+RpGeP7P/tAlmRm0YbwnylzTjM mJHzCShwoqz4MkvswMhxPAXOskqxbrODRQtEGR+ILkmsqaDqjSdjOegmL/d2TJooqYgd vxVdbjjzSdjXvuhAZPG5Vw896Q2M4fx+QyPcjJFU9wuyYl2Bl7SXrxrEHj15K9pPwye8 En2SF3T8/GTGEg18NiII2YseIRNxu/xGVGfANwH1NzqK01wLrAu804wDeZnstckWXJKD OjHcI9RA+EmsLVOBlQMzw1vroTtfJZKh1qyI2Yz/6wzeoHiZxjPeZHpT/Rxob98z2AjE IkeQ== X-Forwarded-Encrypted: i=1; AJvYcCWayWbnkyur1Hy/jNwBPR9cVKR+EX/sBb4T0oCPmWESF1CWvOTNabPUbH2Z9Rk/XjWKM1sWgviK3CRQXtfmbOGUtns= X-Gm-Message-State: AOJu0YybDvethIriLPDK0D342k4QZ55dfa2fsKHJqdgqw6AUqhOkv1mu qRbW1aoO0NbFyDgjjYoGbn5jEmxtMMBhKcybh50+O+5Vl1N+OAitduMi4+43Q0sey2lP4zUjQz7 eZhSlmXNUoJw08fGjwKfT9xAzhwtCmzu2OKla X-Google-Smtp-Source: AGHT+IHGBa7tMMleiZKIyfq04qQxdw3xbaO8yY7nGHAFS1LwAn2FIimhO36Sml74NHR419/S58AeVS848bcSO81YVbs= X-Received: by 2002:a17:902:f789:b0:1e0:c571:d652 with SMTP id d9443c01a7336-1ed851171f3mr1404605ad.1.1714885790351; Sat, 04 May 2024 22:09:50 -0700 (PDT) MIME-Version: 1.0 References: <20240504003006.3303334-1-andrii@kernel.org> <20240504003006.3303334-6-andrii@kernel.org> <2024050404-rectify-romp-4fdb@gregkh> In-Reply-To: From: Ian Rogers Date: Sat, 4 May 2024 22:09:39 -0700 Message-ID: Subject: Re: [PATCH 5/5] selftests/bpf: a simple benchmark tool for /proc//maps APIs To: Andrii Nakryiko Cc: Greg KH , 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, Arnaldo Carvalho de Melo , "linux-perf-use." Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 071FD140006 X-Stat-Signature: spnsfyhti4ajbpad46hokyxk361rbzs6 X-Rspam-User: X-HE-Tag: 1714885791-250302 X-HE-Meta: U2FsdGVkX1+ypWYjm11cBNl8o1qvnyQKV5P2UFjwJ0w5GhwAqJjDzvrc8SSxv86o3rJQ/rZFeOJkxLUDYxR1LSL/AJ/Ki/is9AaTa5twGpq9+kSipDvXJ78sfEjMvowcgYFgCF38FiUTJRLWG+IEujNRKiBOn/mKrKS1T9V3KN43AmBAp5U1n5xd6FrEfR/GQOK/aOq7iJFEWo2amUlCAtyILLzZFnKGn69ac8otl2jIN9H9xkRkZYeFCC6COhVFsNxZeG+Sn6pR7Kc1oazY43ophnG0NfBge0xD5Hdzql1B0Ws9/uwEVsqpY49WatPOtKVlfrrG5qkFFF/5f7/PnYvVxobzrb3VhFvqQkO8xorGw7PI7DOdt0JMdVaibYnKWJFqzQ1ZXYNQG2LXxSaLKcUPWfvCopdzR3DWeegMZD4iRvOcbr285A1RbfotuYAZhbTaru2UiYlaf1/DUALdWzjkppSzQ+SGGcuXP50/l+93mLNeg5eka1jJOXK0j6c3FSIWy6DnxjJY6p7UC0AktdpFDY9RU8KfVnslrwfYOvIRGj6WL2tQ5Be7nxP0vfsb38JDowo+a2VkDIEz4Zt9x2fazreohMNJ5SlYTI/0dpMyBsCOvKqhCSaYiK8AZ59Fjfz0iCT6zEv7C1bcumG+H4RxeOUJeSq+ogepME2Lx1HtFNuewfe8A7/njpYLZ6N7qAEv99CpLcn4cdgxd5DaldA22fPFSh85zKQrBYVr30bTagWTkK2PHjMseN835H37rdiIJoa4eOEABtfWE2knShB8x+1SOf6jwpZrA8PCgkhLg4rUgzHZ6GQs5y3TlMWRFuEOWuWdMPWRyAlJj1oJQpKvCch6Sb7B+lZVGwe1R4+fXGMOpTRC4ZN1ra8i1icJH8csA3smeuTtqKrk6oBkIjmMlwqh7P0rnugv6qBaEcq2CqUemA/o9WBIKUOH7Hnn1H6aoGs7Qtk2ZXTuA4N 0hlBvzuO 8bQ2C7KpyHwc0ncVvetIFNyBIE1WqkzrRAFkKvWdx8G97M/TkcU+t1diq5DMiOVxqAOCILGR1e3B4hFXjp+jgSqHHPEonpJ5zZ0qCEWgYf+knZhgiJEQx59Zu8Sg2O/bDAEK9YVPkQjRU0+Zliy80nMEjDYwoP0ScuIT/31pAXfbHexnJMam3pPwXirUZHwbWAvdVHzSNunOunmqkKK9ae2eo5XSqDB8yuz6AQLbi2IWUjl2LU/bBByYDWJ/VQd1bZJ+Icfjt4mJcA/Yr2mY/dmxHH+I/MiDi15NTGqBZIpPy0CCeivE1d5F85ZS3PlOg69hsNPk7yQl2OOquHVBxwTB7lsd4ByTMAjeqM3cpEREXho+Uifb4JibL5mRvKIOTsIsByJTocKyld5KDaszCC2CPruotsZdOQsvN2f5Um56jcfmskpFA0FmscKdA22ILbjneQ80wBcolwT46GiP4+R4C+A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, 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 2:57=E2=80=AFPM Andrii Nakryiko wrote: > > On Sat, May 4, 2024 at 8:29=E2=80=AFAM Greg KH wrote: > > > > On Fri, May 03, 2024 at 05:30:06PM -0700, Andrii Nakryiko wrote: > > > Implement a simple tool/benchmark for comparing address "resolution" > > > logic based on textual /proc//maps interface and new binary > > > ioctl-based PROCFS_PROCMAP_QUERY command. > > > > Of course an artificial benchmark of "read a whole file" vs. "a tiny > > ioctl" is going to be different, but step back and show how this is > > going to be used in the real world overall. Pounding on this file is > > not a normal operation, right? > > > > It's not artificial at all. It's *exactly* what, say, blazesym library > is doing (see [0], it's Rust and part of the overall library API, I > think C code in this patch is way easier to follow for someone not > familiar with implementation of blazesym, but both implementations are > doing exactly the same sequence of steps). You can do it even less > efficiently by parsing the whole file, building an in-memory lookup > table, then looking up addresses one by one. But that's even slower > and more memory-hungry. So I didn't even bother implementing that, it > would put /proc//maps at even more disadvantage. > > Other applications that deal with stack traces (including perf) would > be doing one of those two approaches, depending on circumstances and > level of sophistication of code (and sensitivity to performance). The code in perf doing this is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/too= ls/perf/util/synthetic-events.c#n440 The code is using the api/io.h code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/too= ls/lib/api/io.h Using perf to profile perf it was observed time was spent allocating buffers and locale related activities when using stdio, so io is a lighter weight alternative, albeit with more verbose code than fscanf. You could add this as an alternate /proc//maps reader, we have a similar benchmark in `perf bench internals synthesize`. Thanks, Ian > [0] https://github.com/libbpf/blazesym/blob/ee9b48a80c0b4499118a1e8e5d9= 01cddb2b33ab1/src/normalize/user.rs#L193 > > > thanks, > > > > greg k-h >