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 5C491C61DA4 for ; Sat, 18 Mar 2023 08:34:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED150900004; Sat, 18 Mar 2023 04:34:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E58CD900002; Sat, 18 Mar 2023 04:34:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD2A6900004; Sat, 18 Mar 2023 04:34:13 -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 BB038900002 for ; Sat, 18 Mar 2023 04:34:13 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 83E4DA7018 for ; Sat, 18 Mar 2023 08:34:13 +0000 (UTC) X-FDA: 80581356786.07.8EC30C3 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf23.hostedemail.com (Postfix) with ESMTP id 9EECF140008 for ; Sat, 18 Mar 2023 08:34:11 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=oBS8WOmu; spf=pass (imf23.hostedemail.com: domain of olsajiri@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=olsajiri@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679128451; 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=IAwD34h/OR3i3A5T4/iVtj4bFuK5KpGaAWZE6okZa44=; b=K6poY+9orY2zvj5bbGAppyKWAFtD2Ee9e6WipDbH7ZiANU0FmJwmUbFFv+ZA1zkZrIBt7J +wQAYGFXfNo/UOjqRV+1FZzEDKPXkNFHcYj39eKML/9WoRh9th8cYkF3U0oxvU15fn2F9A e3zYZ/p1A6NpBmjCXmOOX4alP72JRs0= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=oBS8WOmu; spf=pass (imf23.hostedemail.com: domain of olsajiri@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=olsajiri@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679128451; a=rsa-sha256; cv=none; b=8cpl02K5iz7N97zrgz2f3O8BHBCeywvzsVWzdkUEaizSwCO713KJwD8abc6NS+B1SeAqai AyBxWP72UxiR1ZU5iokIr6jPoxYHYY8+feQWQ6d9wtCyox+bvo8ZsMaj9so7deoKnnSHnM 8LE0z6vJFmwkucSdzgcWfQhLMGyqtj8= Received: by mail-wm1-f41.google.com with SMTP id x22so4594207wmj.3 for ; Sat, 18 Mar 2023 01:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679128450; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=IAwD34h/OR3i3A5T4/iVtj4bFuK5KpGaAWZE6okZa44=; b=oBS8WOmu7YIDUWHqFvE/fS7jKf9hfbjBtL5s7f5hhQi6MTlTn/f/ZhngsXnXXGk1MQ 196LcZ0kxYFjkBoe3cNgFDpRyQETqJKw+Stdl+NzB9bLaqVZ7j+VHxaYgEM9h8hJN9Wf jVU/1gdrAjwHFDoEDQTXeWX+WK8Nk67sO2myGzSBDZp70isYDPJQDvkCeVHFj+RZcT2j ykV/vz1LvRuuwgja+QHiV0ZLIwTFH1/hxTXhKDHpsQ73u2sYLtS03LC6qQOm2DXHR6hM sMB+R9WrrnJg88qejqvkajSCLRQFThbR/68Xo2iFruRP2zs/5e9jgAiFLvcCZjSsQPUF Tqpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679128450; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IAwD34h/OR3i3A5T4/iVtj4bFuK5KpGaAWZE6okZa44=; b=MgGa0SvBBd+HlnBUjhvN2uMCnjcP9u/Vlhs4Mc5Bc4myRpMQ5UEDKzmeUruwW7iIPc 3So3Lo0rLRC1tZls5+5dkhQ2oRL2e09rQS+LHxXeeVuQgxfAbzC00WaFMF/sY+Aoa4im RzQ14IUDEKgvtGsRuddJFhS0XTETmXl/pvktO1NCCUV9cUB8n3dDpurrObBeZ9QM4K/g WQ2pisgFv8fpD10pVZUB1lFiixcKKa970rtS6Hw2oVof0sBGzQqa0Kl7FXKm7I0oEUlt qGJGGNb8Nh72aE+LzNxOhNFyAFLVpbfirNlPJAANMmIRtHezt62jYR85vJXUkAn/4L2Y Sovg== X-Gm-Message-State: AO0yUKWKCTV2OywO6hTGhhS8LA/hMW9J3cI55J9TRKsPKVqrDIqaXZBj fGPV+WsidHWBsnkbKc+cOCE= X-Google-Smtp-Source: AK7set9hn+u/qdIBUzB7AochpnvZos9W3Ofl0dnvwk/TIEMDl5Ld0oUM8Oo8fYzs0HVqTAFXPv3J6g== X-Received: by 2002:a05:600c:4f07:b0:3ed:3cec:d2ec with SMTP id l7-20020a05600c4f0700b003ed3cecd2ecmr9784588wmq.15.1679128450203; Sat, 18 Mar 2023 01:34:10 -0700 (PDT) Received: from krava (net-93-147-243-166.cust.vodafonedsl.it. [93.147.243.166]) by smtp.gmail.com with ESMTPSA id t1-20020a7bc3c1000000b003e1f2e43a1csm4073432wmj.48.2023.03.18.01.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Mar 2023 01:34:09 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Sat, 18 Mar 2023 09:34:05 +0100 To: Andrii Nakryiko Cc: Al Viro , Matthew Wilcox , Ian Rogers , Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Daniel Borkmann , Namhyung Kim , Dave Chinner , kernel-team@meta.com Subject: Re: [PATCHv3 bpf-next 0/9] mm/bpf/perf: Store build id in file object Message-ID: References: <20230316170149.4106586-1-jolsa@kernel.org> <20230317211403.GZ3390869@ZenIV> <20230317212125.GA3390869@ZenIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: afpe6fexq7e7cwszssydj5q5zfwgwdrg X-Rspamd-Queue-Id: 9EECF140008 X-HE-Tag: 1679128451-841136 X-HE-Meta: U2FsdGVkX19sDnCf6NFW66kiLg1CXJdPe9oNwOx/tpbJxAJemiwL+Vkj5vjhAgtMfuae4kEGRoUey++wUJuOw//CjfQH6ic/JKqArttQUq0Ydm/gxTSinrMFBXyQvi5ihTbc2UZyr3SPDy9HYuzVz5+u8zWgztBjvwsIdX7cI69hQmG3aW3krzm688RGWSgb+Rzaiwb72qqAXtTtTj6XFg/u1O2+2RiNqYel9thYZN8qN+XeGGESn8nBwH95nMKb0KOPiGaIp/x79cNW+2ctR5+86ZrzEbpadHu/Ca2R9MOhee4IVdPPJzx/PH34gPmYLBNAj4JEab7qQ5IxWoOQFHM/zh9KPT14QkxB8TO4MQHPez4Ok85D666wK75c17nG6+hjBo3sHEBOb2Y/V4WnocvwaEZOyhoR9H/E3V4pYbcYFEhlXgCJXoc7Twz9jEo/dMw75vKerMDJ80ErJ+YTV6wOahvIw0tqceX3TG0wlJJkkX8prwnb/IgQSPWqCZKVhI7WayXGw9mZ7hhk9Rj71iF2RP9ROXDZF8kZC9ng/jXIOS5z3gXiI/IWH5GEkd85CTgmPPZ4wHra2dDz1+YZaQ9CG4J6HkX1/Nyqd7kHsW/jW788tig80i6X71N8mm3DgXVOwBVNgkWND77nUqQMqQL1egMqeLCkW5NHCrvsVERXSG8d3zDsSl6icACQuR2Vtc/cQpdhfu8yp/InfBO7HwRhDbGNWOKgQxfcOtX0u1yIBk6wswHBrDPfXn89JZI3vKNA17PDq6m5W+BGzXDZYNmpaKTPLXiuG03l9gc+MEJpR0p/v7///mynnAvklo0gXu0Bra89GrcPJ8XFfNUwX43IrOVdo2IiLOGpdUQMwURN0hxvUZZsDJM2Ii0f4cQhpBlBDsfH89SoPdF2xGPY++B2wfqr+2zr2uWcbM4kpgphuMBkKdTJYwF7jXc+e/fkVT3fl2wQXCy/dyT3ZFg n3D0SyvZ R+e9R5BkaaNEiWC61RFMgZ/ulThvCc9IJjz9mF+wCQHzS+hNzXN72XcE25djZNpCMd48YM70VO7cQ5eLAq0A/OLZyHsXSxWRJhiulg9wUr6dtkigDIWGSc2/dYzxZg63ZsX08VfpFiLJ+7sa0XjczP/t2Rczp20iwcCmyOG4VCG6NderV7rhFmGyBBa86li7c1LZchoUndJOmsj8vDC+o0RAVaLwokJBPIEZgqLxpPTRpwJX71q/xXfWc3xocy/T7unslC21j6ylxYPic5uxuRRNZxV3UDf3w497FOxl8T4LhZE/G9RlWeqNc+S2A3Og4IWk/aQ61eCbWuXKL4CY/WlXLiUuFWzEpulLkYf3gjqY+pt2mZUCmvbwup+4TCiRhG0vZbpCja2hXfMhuTyoeKG3+DzFJP+as3bT3aVwpiDe6+TjcqZTsJdTBjDLZdiPxivinj+pgBOia7qKLhUJvXi+3szOLX5zDY+CfjRAQ2a2+ve+zgv81g6OjwkXXEyt2UphH 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: On Fri, Mar 17, 2023 at 11:08:44PM -0700, Andrii Nakryiko wrote: SNIP > > > That does depend upon the load, obviously, but it's not hard to collect - > > > you already have more than enough hooks inserted in the relevant places. > > > That might give a better appreciation of the reactions... > > > > One possibility would be a bit stolen from inode flags + hash keyed by > > struct inode address (middle bits make for a decent hash function); > > inode eviction would check that bit and kick the corresponding thing > > from hash if the bit is set. > > > > Associating that thing with inode => hash lookup/insert + set the bit. > > This is an interesting idea, but now we are running into a few > unnecessary problems. We need to have a global dynamically sized hash > map in the system. If we fix the number of buckets, we risk either > wasting memory on an underutilized system (if we oversize), or > performance problems due to collisions (if we undersize) if we have a > busy system with lots of executables mapped in memory. If we don't > pre-size, then we are talking about reallocations, rehashing, and > doing that under global lock or something like that. Further, we'd > have to take locks on buckets, which causes further problems for > looking up build ID from this hashmap in NMI context for perf events > and BPF programs, as locks can't be safely taken under those > conditions, and thus fetching build ID would still be unreliable > (though less so than it is today, of course). > > All of this is solvable to some degree (but not perfectly and not with > simple and elegant approaches), but seems like an unnecessarily > overcomplication compared to the amount of memory that we hope to > save. It still feels like a Kconfig-guarded 8 byte field per struct > file is a reasonable price for gaining reliable build ID information > for profiling/tracing tools. > > > [0] https://drgn.readthedocs.io/en/latest/index.html > > [1] Script I used: > > from drgn.helpers.linux.pid import for_each_task > from drgn.helpers.linux.fs import for_each_file > > task_cnt = 0 > file_set = set() > > for task in for_each_task(prog): > task_cnt += 1 > try: > for (fd, file) in for_each_file(task): > file_set.add(file.value_()) > except: > pass > > uniq_file_cnt = len(file_set) > print(f"task_cnt={task_cnt} uniq_file_cnt={uniq_file_cnt}") great you beat me to this, I wouldn't have thought of using drgn for this ;-) I'll see if I can install it to some of our test servers thanks, jirka