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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C77EC433E1 for ; Wed, 27 May 2020 21:27:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2A36B207D8 for ; Wed, 27 May 2020 21:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590614867; bh=HUaCb3PCCc2Pw/hRjP9hPvQCIfIdC6bqDipqt+IXdOU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=tKohEepTXOy2n84LVUlaraxHQjYZ0TXFgbSHphrYHAbDHmK6xuLmSIK2hlvZbxtSW 7vgcqJns2mn5E4S2TD4oWyITF+43Ecp3L4SeUsGqxNR1b3yov0YQTX4TRwv+dw2C3p PWtRGzrh6Dmz4w/pQRgeW5PAPZo0eTcSaaybb13E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387706AbgE0V1q (ORCPT ); Wed, 27 May 2020 17:27:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:44994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbgE0V1p (ORCPT ); Wed, 27 May 2020 17:27:45 -0400 Received: from kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net (unknown [163.114.132.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9BB422078C; Wed, 27 May 2020 21:27:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590614864; bh=HUaCb3PCCc2Pw/hRjP9hPvQCIfIdC6bqDipqt+IXdOU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=e27RQsyjYiPcLJYK/eWYlxTA6Bn/y9CgNn3E+9GG9h7m/a5G1frb/+wAOfPx/3NE5 gAW7R0FZcXgWATLm2Kr9E7RUabkNwvrP/VCkwQjepQzJGb/QKMmOyRYKTiSGdUTuRr 2S31ZwxZjPaH1lEr34iVlwoqokOeCs+hilL79l5o= Date: Wed, 27 May 2020 14:27:41 -0700 From: Jakub Kicinski To: Paolo Bonzini Cc: Emanuele Giuseppe Esposito , kvm@vger.kernel.org, Christian Borntraeger , Jim Mattson , Alexander Viro , Emanuele Giuseppe Esposito , David Rientjes , Jonathan Adams , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, Andrew Lunn Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics Message-ID: <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> In-Reply-To: References: <20200526110318.69006-1-eesposit@redhat.com> <20200526153128.448bfb43@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <6a754b40-b148-867d-071d-8f31c5c0d172@redhat.com> <20200527132321.54bcdf04@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 May 2020 23:07:53 +0200 Paolo Bonzini wrote: > > Again, I have little KVM knowledge, but BPF also uses a fd-based API, > > and carries stats over the same syscall interface. > > Can BPF stats (for BPF scripts created by whatever process is running in > the system) be collected by an external daemon that does not have access > to the file descriptor? For KVM it's of secondary importance to gather > stats in the program; it can be nice to have and we are thinking of a > way to export the stats over the fd-based API, but it's less useful than > system-wide monitoring. Perhaps this is a difference between the two. Yes, check out bpftool prog list (bpftool code is under tools/bpf/ in the kernel tree). BPF statistics are under a static key, so you may not see any on your system. My system shows e.g.: 81: kprobe name abc tag cefaa9376bdaae75 gpl run_time_ns 80941 run_cnt 152 loaded_at 2020-05-26T13:00:24-0700 uid 0 xlated 512B jited 307B memlock 4096B map_ids 66,64 btf_id 16 In this example run_time_ns and run_cnt are stats. The first number on the left is the program ID. BPF has an IDA, and each object gets an integer id. So admin (or CAP_BPF, I think) can iterate over the ids and open fds to objects of interest. > Another case where stats and configuration are separate is CPUs, where > CPU enumeration is done in sysfs but statistics are exposed in various > procfs files such as /proc/interrupts and /proc/stats. True, but I'm guessing everyone is just okay living with the legacy procfs format there. Otherwise I'd guess the stats would had been added to sysfs. I'd be curious to hear the full story there.