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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 3D178C433E0 for ; Wed, 27 May 2020 21:44:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 108162075A for ; Wed, 27 May 2020 21:44:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QEqoUDlI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726693AbgE0Vo4 (ORCPT ); Wed, 27 May 2020 17:44:56 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:47552 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725930AbgE0Voy (ORCPT ); Wed, 27 May 2020 17:44:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590615892; h=from:from: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; bh=fBvAWYmBdzgrA5U0LT3xtBczNhEDcnN6W5IKb+q9W/4=; b=QEqoUDlIvmI2hBiD4wCZGEVXSoFKikYClEgisZAokONZIGycxBOUcu9FhKgkp0XiC4dDmA +/5YHL25q8RLW57uN5cwLoa7ALTzjPHsZ8V2MygNEyWV73VLQc1JG3/gB058ZGMP6AkqPA FJaPGnugxh9r1/I3f0eVuB7jOckuwHw= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-473-aSBTTzSIMxi_-BB5z1QEXw-1; Wed, 27 May 2020 17:44:49 -0400 X-MC-Unique: aSBTTzSIMxi_-BB5z1QEXw-1 Received: by mail-wr1-f72.google.com with SMTP id l18so6658481wrm.0 for ; Wed, 27 May 2020 14:44:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fBvAWYmBdzgrA5U0LT3xtBczNhEDcnN6W5IKb+q9W/4=; b=CfOArljPdXkWPA7Tt9xrrv6zsmNd5zA0G9sdBbYDeS13RpKkkVTywhvMozGlMgS9RS w3d0wdQscscB0gXmfLzJW9bKJ9JRcb/6zHyyyltWPiRDy3YRHHg8Dg4SAc6o2excbxRm odjjSHYeYZuu7OpV6jNJaqwXjikV39ZV0Z8ntkL5u6178iMh+0xenZy45gTcvSIeqiMk dY5xSD2Xn1dllBCBgaauM3Pb4IUXMYx411EnCffh9/F9uN3Rx2ITAoqEuzE+z/+FeRUM kY2xXoSVpZcJO0xz3YpkFq3XLItfv28m5tREN1r9xX22xcG3dL2j1thsAy3nS5g1saAj B+cg== X-Gm-Message-State: AOAM531gIOfrpyECv4hQbgMIy/G7UkifhNjSPqDKFU8lRRrr6K86jdUm cLITH3E/WackNhlwArCm1VxZP7yj48B/61zxN1LFbTb+4DC8TCxSDQ5KBv+ev4ppV4wwoQTOsxV E+C3ShNzYeHC8pkgPxlNahnIL X-Received: by 2002:a1c:790a:: with SMTP id l10mr144589wme.80.1590615888698; Wed, 27 May 2020 14:44:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3Af0J2CmuPpUG32rxwXfc1KYndN+k+SQB+Tn++8tDC1cfUbE9HPS7Kypz3xsxeZWawipQoA== X-Received: by 2002:a1c:790a:: with SMTP id l10mr144569wme.80.1590615888450; Wed, 27 May 2020 14:44:48 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:3c1c:ffba:c624:29b8? ([2001:b07:6468:f312:3c1c:ffba:c624:29b8]) by smtp.gmail.com with ESMTPSA id j135sm4749631wmj.43.2020.05.27.14.44.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 14:44:47 -0700 (PDT) Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics To: Jakub Kicinski 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 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> <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> From: Paolo Bonzini Message-ID: <925502d6-875a-4d19-b574-1ffd47a9c2ce@redhat.com> Date: Wed, 27 May 2020 23:44:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/05/20 23:27, Jakub Kicinski wrote: > 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. Got it, thanks. But then "I'd hope that whatever daemon collects [BPF] stats doesn't run as root". :) >> 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. Yeah, it's a chicken-and-egg problem in that there's no good place in sysfs to put statistics right now, which is part of what this filesystem is trying to solve (the other part is the API). You can read more about Google's usecase at http://lkml.iu.edu/hypermail/linux/kernel/2005.0/08056.html, it does include both network and interrupt stats and it's something that they've been using in production for quite some time. We'd like the statsfs API to be the basis for including something akin to that in Linux. To be honest, it's unlikely that Emanuele (who has just finished his internship at Red Hat) and I will pursue the networking stats further than the demo patch at the end of this series. However, we're trying to make sure that the API is at least ready for that, and to probe whether any developers from other subsystems would be interested in using statsfs. So thanks for bringing your point of view! Thanks, Paolo 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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 A8A11C433E0 for ; Wed, 27 May 2020 21:46:47 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 07E582075A for ; Wed, 27 May 2020 21:46:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="f5+m773z"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="f5+m773z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07E582075A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 49XPYJ1L26zDqW4 for ; Thu, 28 May 2020 07:46:44 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=207.211.31.81; helo=us-smtp-delivery-1.mimecast.com; envelope-from=pbonzini@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=f5+m773z; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=f5+m773z; dkim-atps=neutral Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 49XPWH2Fj6zDqS7 for ; Thu, 28 May 2020 07:44:56 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590615893; h=from:from: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; bh=fBvAWYmBdzgrA5U0LT3xtBczNhEDcnN6W5IKb+q9W/4=; b=f5+m773zVpBBE7zzZUGItca2jTsBlNth0jKdTSy5+mCt1NX75m/yyZQErftK7UOx3wlA6l rUqADTpSpMzfNQrdBNnEdxMc79TH+hHOV9kDcOhID+oCgbm9XBhbi8hc23ZSSK3XuiD5hz Jew1GLjd0dzgvlFpG0zU/gMFEhCVg5M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590615893; h=from:from: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; bh=fBvAWYmBdzgrA5U0LT3xtBczNhEDcnN6W5IKb+q9W/4=; b=f5+m773zVpBBE7zzZUGItca2jTsBlNth0jKdTSy5+mCt1NX75m/yyZQErftK7UOx3wlA6l rUqADTpSpMzfNQrdBNnEdxMc79TH+hHOV9kDcOhID+oCgbm9XBhbi8hc23ZSSK3XuiD5hz Jew1GLjd0dzgvlFpG0zU/gMFEhCVg5M= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-473-vflnJW1CPSKaRa9HeO4dmw-1; Wed, 27 May 2020 17:44:49 -0400 X-MC-Unique: vflnJW1CPSKaRa9HeO4dmw-1 Received: by mail-wr1-f72.google.com with SMTP id n9so11720763wru.20 for ; Wed, 27 May 2020 14:44:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fBvAWYmBdzgrA5U0LT3xtBczNhEDcnN6W5IKb+q9W/4=; b=bWmHNraud+gZdLzmbbS1omK435EMFHnm6VR/milnI+Ql67qTaNABwUWYeaxzNrnmj0 9UMBJZoWD2VVL1MDjiHZAV/QhQ6ZG1jYc/JyopF5E5uImTJ5s704qd/FBnhJ1/j5s8uS UkyPR9oQ+icyneEj0WgbjnRf3d4xprJRIfJRpzjG8B8VSoX00bn6Vd4Q7DQ04RKCSRgu oHpJ19xSHR/r+Bqoyk980A8+iSUy5GqclY+U/XugA1e7wfLv1Igdhxg2eNqRrUDq74Bo FvA874bZnPgW2ioJcJT0I/4igrwejFUSBrbd4D19WYY0emS+DF3sTcRV5XQ28DWzZAUI aWag== X-Gm-Message-State: AOAM531TewTfNH4+qpuxxVG4fIZEZBSclxgqckJBfivxnKzV1MAanCnx 1YgxzSyg9VTPsJe+PAcIZz3FQJ4se6Djg9rYkXJqErX0mZtP7Qg159PLFR2k10xeygaZoNQ5mvc zLpdTblxfvNzKNuxq+upmLXMKvg== X-Received: by 2002:a1c:790a:: with SMTP id l10mr144602wme.80.1590615888724; Wed, 27 May 2020 14:44:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3Af0J2CmuPpUG32rxwXfc1KYndN+k+SQB+Tn++8tDC1cfUbE9HPS7Kypz3xsxeZWawipQoA== X-Received: by 2002:a1c:790a:: with SMTP id l10mr144569wme.80.1590615888450; Wed, 27 May 2020 14:44:48 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:3c1c:ffba:c624:29b8? ([2001:b07:6468:f312:3c1c:ffba:c624:29b8]) by smtp.gmail.com with ESMTPSA id j135sm4749631wmj.43.2020.05.27.14.44.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 14:44:47 -0700 (PDT) Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics To: Jakub Kicinski 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> <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> From: Paolo Bonzini Message-ID: <925502d6-875a-4d19-b574-1ffd47a9c2ce@redhat.com> Date: Wed, 27 May 2020 23:44:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Emanuele Giuseppe Esposito , linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, Emanuele Giuseppe Esposito , linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org, Jonathan Adams , Christian Borntraeger , Andrew Lunn , Alexander Viro , David Rientjes , linux-fsdevel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Jim Mattson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 27/05/20 23:27, Jakub Kicinski wrote: > 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. Got it, thanks. But then "I'd hope that whatever daemon collects [BPF] stats doesn't run as root". :) >> 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. Yeah, it's a chicken-and-egg problem in that there's no good place in sysfs to put statistics right now, which is part of what this filesystem is trying to solve (the other part is the API). You can read more about Google's usecase at http://lkml.iu.edu/hypermail/linux/kernel/2005.0/08056.html, it does include both network and interrupt stats and it's something that they've been using in production for quite some time. We'd like the statsfs API to be the basis for including something akin to that in Linux. To be honest, it's unlikely that Emanuele (who has just finished his internship at Red Hat) and I will pursue the networking stats further than the demo patch at the end of this series. However, we're trying to make sure that the API is at least ready for that, and to probe whether any developers from other subsystems would be interested in using statsfs. So thanks for bringing your point of view! Thanks, Paolo 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=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 E855DC433E0 for ; Wed, 27 May 2020 21:45:18 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A926420835 for ; Wed, 27 May 2020 21:45:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PvjwI2qo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="e5pa/J2n" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A926420835 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qFR7z2f8grk/evoP2DayJZpzze3/DPezAqzjkcaG72A=; b=PvjwI2qo2IJ5wt /Xd6PyFzmQtHC0kmJhmBQrXN4V2w61WRDhnlfT74TIKtfp7VWudfZSgTp3VxorRWAqztwDyfQiHOp tuHz5gViGo3pCxCXcP/v0c1ff2D5cMq1RM6UB/xQW6zarPtvBPIExGEtL2LEsJWbHsE39z92BxQbm vFSjKdEsAemvv47Cd9J9VGR5hZw9e5BAmB8B/L7+fWqjr027ymcmGoPs2QBDvq5oedr5L5e5WUcss epyB64nUDBpFJXD7YekLVcqkFhqX1u8B2QeEds/OTe5w3fqHOwY6SjGXKPXKXMIkI6Cad0HipSzs5 Yv/ag1v9eKiVkIT5yvGQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1je3rD-00019w-V8; Wed, 27 May 2020 21:45:03 +0000 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120] helo=us-smtp-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1je3r9-00017J-V3 for linux-arm-kernel@lists.infradead.org; Wed, 27 May 2020 21:45:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590615894; h=from:from: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; bh=fBvAWYmBdzgrA5U0LT3xtBczNhEDcnN6W5IKb+q9W/4=; b=e5pa/J2nRnQ8WudYJBwm8zN6/wgx7gvJjV/SVlLp0Hzf7CoNns4MfuoEyEDJbiPXWPRKzP 1DsFpd/TzoC27nwii9uTUKARqxtvq9yxtasx7g4OB6NZ7A7dAxHm2pe7HVUFIQN6XD+4ok g3JHOQTT5ZmPGWnuoid2EVkaGZuqtNk= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-212-jXPDNM-HOo6-28QJfD61jQ-1; Wed, 27 May 2020 17:44:50 -0400 X-MC-Unique: jXPDNM-HOo6-28QJfD61jQ-1 Received: by mail-wr1-f71.google.com with SMTP id l1so8070925wrc.8 for ; Wed, 27 May 2020 14:44:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fBvAWYmBdzgrA5U0LT3xtBczNhEDcnN6W5IKb+q9W/4=; b=ioAdtPcw96hS2eGPzvM3oLH/JqE9Rkj2d+2+uoD73prf8LOCsXMVdCApO5Ozxs6U2W epubSYc8FdallgpZDmqRN3B4K5JY968un76wWX+7z9zn5iSv49AX+obAX7Osr8I3z8Xq 46YlQpmdcXQBNS4V57/+65grigSznJNpHuvLBcOBCASbJWIhXYu0NUiBkw9/vRmV8cJn Jy3cXYEnaefcAo4e9hY0xPZ3GTfkM4CZWEWMnmvCsrdMvpcxJtUMPcbCfdVi7oEkpLkd +IU8k88dwHK5tgJ1PiOiP+o7rGscnio5aXH05aeHTAq07xdLnyswa/kSa1b0Ag9GCJv7 7VEg== X-Gm-Message-State: AOAM5316Bzmfos3EHZ7xNUtC806TLBxZkVcMLviqMqYrEB4v8oYjV/L4 r8656lFojHEPiwjoqRo77dF1hcqBHZGeI77Bw6uq1Yr5bdEFok+zvnht6g7l+rIzGAScszL9Q4W iZui2U9729vxAEztt/z3+pjZkCbaB1Ei2eaA= X-Received: by 2002:a1c:790a:: with SMTP id l10mr144597wme.80.1590615888699; Wed, 27 May 2020 14:44:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3Af0J2CmuPpUG32rxwXfc1KYndN+k+SQB+Tn++8tDC1cfUbE9HPS7Kypz3xsxeZWawipQoA== X-Received: by 2002:a1c:790a:: with SMTP id l10mr144569wme.80.1590615888450; Wed, 27 May 2020 14:44:48 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:3c1c:ffba:c624:29b8? ([2001:b07:6468:f312:3c1c:ffba:c624:29b8]) by smtp.gmail.com with ESMTPSA id j135sm4749631wmj.43.2020.05.27.14.44.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 14:44:47 -0700 (PDT) Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics To: Jakub Kicinski 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> <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> From: Paolo Bonzini Message-ID: <925502d6-875a-4d19-b574-1ffd47a9c2ce@redhat.com> Date: Wed, 27 May 2020 23:44:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200527_144500_076910_A6787FE1 X-CRM114-Status: GOOD ( 20.05 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Emanuele Giuseppe Esposito , linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, Emanuele Giuseppe Esposito , linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org, Jonathan Adams , Christian Borntraeger , Andrew Lunn , Alexander Viro , David Rientjes , linux-fsdevel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Jim Mattson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 27/05/20 23:27, Jakub Kicinski wrote: > 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. Got it, thanks. But then "I'd hope that whatever daemon collects [BPF] stats doesn't run as root". :) >> 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. Yeah, it's a chicken-and-egg problem in that there's no good place in sysfs to put statistics right now, which is part of what this filesystem is trying to solve (the other part is the API). You can read more about Google's usecase at http://lkml.iu.edu/hypermail/linux/kernel/2005.0/08056.html, it does include both network and interrupt stats and it's something that they've been using in production for quite some time. We'd like the statsfs API to be the basis for including something akin to that in Linux. To be honest, it's unlikely that Emanuele (who has just finished his internship at Red Hat) and I will pursue the networking stats further than the demo patch at the end of this series. However, we're trying to make sure that the API is at least ready for that, and to probe whether any developers from other subsystems would be interested in using statsfs. So thanks for bringing your point of view! Thanks, Paolo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Date: Wed, 27 May 2020 21:44:46 +0000 Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics Message-Id: <925502d6-875a-4d19-b574-1ffd47a9c2ce@redhat.com> List-Id: 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> <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> In-Reply-To: <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jakub Kicinski 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 On 27/05/20 23:27, Jakub Kicinski wrote: > 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. Got it, thanks. But then "I'd hope that whatever daemon collects [BPF] stats doesn't run as root". :) >> 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. Yeah, it's a chicken-and-egg problem in that there's no good place in sysfs to put statistics right now, which is part of what this filesystem is trying to solve (the other part is the API). You can read more about Google's usecase at http://lkml.iu.edu/hypermail/linux/kernel/2005.0/08056.html, it does include both network and interrupt stats and it's something that they've been using in production for quite some time. We'd like the statsfs API to be the basis for including something akin to that in Linux. To be honest, it's unlikely that Emanuele (who has just finished his internship at Red Hat) and I will pursue the networking stats further than the demo patch at the end of this series. However, we're trying to make sure that the API is at least ready for that, and to probe whether any developers from other subsystems would be interested in using statsfs. So thanks for bringing your point of view! Thanks, Paolo