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,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 41EA0C433E2 for ; Wed, 27 May 2020 13:14:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1F4EC208DB for ; Wed, 27 May 2020 13:14:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GKbuSOFw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387897AbgE0NOw (ORCPT ); Wed, 27 May 2020 09:14:52 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:33456 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387722AbgE0NOv (ORCPT ); Wed, 27 May 2020 09:14:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590585289; 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=Xp4IU27b7aXZqohMpJFZPawUcolyfH/CQm0FvETLmFY=; b=GKbuSOFwA4M4+1MFHVWM8sWZB6cZGYKaKIMmGO6M5EKsyVOPMt6E4jEQCMyFgU85YMfjvR bClmprTRRYPDWnpafwpn07eHkMe433eIvy/b+7uyQOS9ViC/GLtM6ZLsTZgTIOrb51oJvE 3gbPfKlCJxnuTdMqO1KG7hFPqZywHi0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-499-_ug3VhbQOrqzqVJ7fKfNhQ-1; Wed, 27 May 2020 09:14:45 -0400 X-MC-Unique: _ug3VhbQOrqzqVJ7fKfNhQ-1 Received: by mail-wm1-f72.google.com with SMTP id g84so833870wmf.4 for ; Wed, 27 May 2020 06:14:45 -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=Xp4IU27b7aXZqohMpJFZPawUcolyfH/CQm0FvETLmFY=; b=QSRpTyKeCqSbhd0YY979hZyx56DpZ+yZfXSqhaBdz4NX9HUuaQuiUUyI5VhqlCLEhV ancxNv/I7abaOsQSD1thkJvzIEBwANmaTiimht1pp4XRaGtZOvFuWnr9tA0sczMR94HX dzw0DKnOe/3oMG/yC7rydTZIsK9JPgVhQchKDdShhwkyxSLyFpCUa4RH+UezVVJI+Qo2 Po3uYl8eGNYBf6HMpme6ui9fG7WVVf3pk7s7PEeyve5LAkdlqyiYqkfGN7siAye6uwja XQkNvEYv/VSkhXnyU7eJ67xkMzv83cv7zDZPQd10HqaAa4iZcSXKeppdK6exESuy+DXe jF2Q== X-Gm-Message-State: AOAM533R3Mu2eSHhkyHAUr7Pagta5q/Rm7bgbwo42cs5ZzcQGe0wpMXx Wz60yea8CQ3kjcqnl0VFrdDWxOQJCzPwXz/NTtqCygcXrwwG2FQ8jhH11pZnY8DIbQ5rFjZKzd+ bVccK+NIXVe+T3DAdjfJQgh6n X-Received: by 2002:a1c:1b17:: with SMTP id b23mr4189542wmb.3.1590585284261; Wed, 27 May 2020 06:14:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXDD9pd6xDx85wKJ6DSUd0+jHdsTLXsbOgS1BfL3siVJ+UTokB2SEyRQkeYWpyFjB2Klsulg== X-Received: by 2002:a1c:1b17:: with SMTP id b23mr4189496wmb.3.1590585283890; Wed, 27 May 2020 06:14:43 -0700 (PDT) Received: from localhost.localdomain ([194.230.155.225]) by smtp.gmail.com with ESMTPSA id r4sm2825862wro.32.2020.05.27.06.14.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 06:14:43 -0700 (PDT) Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics To: Jakub Kicinski Cc: kvm@vger.kernel.org, Christian Borntraeger , Paolo Bonzini , 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> From: Emanuele Giuseppe Esposito Message-ID: <6a754b40-b148-867d-071d-8f31c5c0d172@redhat.com> Date: Wed, 27 May 2020 15:14:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200526153128.448bfb43@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed 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 >> >> The file system is mounted on /sys/kernel/stats and would be already used >> by kvm. Statsfs was initially introduced by Paolo Bonzini [1]. > > What's the direct motivation for this work? Moving KVM stats out of > debugfs? There's many reasons: one of these is not using debugfs for statistics, but also (and mainly) to try and have a single tool that automatically takes care and displays them, instead of leaving each subsystem "on its own". Sure, everyone gathers and processes stats in different ways, and the aim of this tool is to hopefully be extensible enough to cover all needs. > In my experience stats belong in the API used for creating/enumerating > objects, statsfs sounds like going in the exact opposite direction - > creating a parallel structure / hierarchy for exposing stats. I know > nothing about KVM but are you sure all the info that has to be exposed > will be stats?I don't understand, what do you mean here? > > In case of networking we have the basic stats in sysfs, under the > netdevice's kobject. But since we're not using sysfs much any more > for config, new stats are added in netlink APIs. Again - same APIs > used for enumeration and config. I don't really know a lot about the networking subsystem, and as it was pointed out in another email on patch 7 by Andrew, networking needs to atomically gather and display statistics in order to make them consistent, and currently this is not supported by stats_fs but could be added in future. In addition, right now it won't work properly if the networking namespaces are enabled. That is another issue to take into consideration. That's also why I marked patch 7 as "not for merge" Regarding the config, as I said the idea is to gather multiple subsystems' statistics, therefore there wouldn't be a single configuration method like in netlink. For example in kvm there are file descriptors for configuration, and creating them requires no privilege, contrary to the network interfaces. Thank you, Emanuele 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 B473DC433E0 for ; Wed, 27 May 2020 13:22:42 +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 64B2820899 for ; Wed, 27 May 2020 13:22:42 +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="GKbuSOFw"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OKXbYDqK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64B2820899 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 49XBMg38w2zDqTl for ; Wed, 27 May 2020 23:22:39 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=207.211.31.120; helo=us-smtp-1.mimecast.com; envelope-from=eesposit@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=GKbuSOFw; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=OKXbYDqK; dkim-atps=neutral Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (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 49XBBl1MYMzDqTD for ; Wed, 27 May 2020 23:14:53 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590585289; 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=Xp4IU27b7aXZqohMpJFZPawUcolyfH/CQm0FvETLmFY=; b=GKbuSOFwA4M4+1MFHVWM8sWZB6cZGYKaKIMmGO6M5EKsyVOPMt6E4jEQCMyFgU85YMfjvR bClmprTRRYPDWnpafwpn07eHkMe433eIvy/b+7uyQOS9ViC/GLtM6ZLsTZgTIOrb51oJvE 3gbPfKlCJxnuTdMqO1KG7hFPqZywHi0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590585290; 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=Xp4IU27b7aXZqohMpJFZPawUcolyfH/CQm0FvETLmFY=; b=OKXbYDqK8qEhgHGMi+5lqrNOYySLaMwMfc4AIy4Qf9Ina6VoCdZKBRHiQfT89NnwaHqMpW d5hDOcs1HunTkFgcEvRclkDumJvHYJ2/9N9MbUmRsBuJymvNRcllPOvGm2z0hpM6XIwjtR 74ntJf2BUSQ9Aly1BE5cXLKW2lpMtY4= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-351-Qganu8ThMLaYO0Xec8ljDg-1; Wed, 27 May 2020 09:14:45 -0400 X-MC-Unique: Qganu8ThMLaYO0Xec8ljDg-1 Received: by mail-wr1-f69.google.com with SMTP id y7so11216976wrd.12 for ; Wed, 27 May 2020 06:14:45 -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=Xp4IU27b7aXZqohMpJFZPawUcolyfH/CQm0FvETLmFY=; b=mugBg5+9O1aAbYKBzj2QnQ9JJNZVZJyNEBIeWz+jh3cboMe00NdR4Cy+L2qXi6Rdzu DdFbuLRHsiHKCphzPnxDVnusfFmsVXOpQucKvOzmRbD3peuX3rgwBO2cZahCwZst4q8b Rvz5O00qc1a1FDZp7966wiRVHnEVpsxw/QJMge7in81nvpz+gRZN7jZ7XJiWK66Fe4wB 1r2PLEmztI68XTL4OPdWU7v4xH5GACX6DX/XlykMRjz4KROmIrzOunvrO8N/PwLnzcvx B05q5nuOXkP3C+Tv+k8WwHc5a9uhk//UIlTy+SLT6NE1wvrIO2WIfLV64zE40yqEpcTr Cxyw== X-Gm-Message-State: AOAM530xbyqD3Ii7hg9fBW/ybjH+zRtlBxIiLr05Qa3fSXxERhN3xAQw UiBhrNAq99ODEyaQA9noGSalf1U4AGocwQyuP00v+0bm2iRagfCFop64weKD9Zqw4scGiFEV2Nx TwSDQG+34O1atBUGOieqFi/6J7g== X-Received: by 2002:a1c:1b17:: with SMTP id b23mr4189519wmb.3.1590585284190; Wed, 27 May 2020 06:14:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXDD9pd6xDx85wKJ6DSUd0+jHdsTLXsbOgS1BfL3siVJ+UTokB2SEyRQkeYWpyFjB2Klsulg== X-Received: by 2002:a1c:1b17:: with SMTP id b23mr4189496wmb.3.1590585283890; Wed, 27 May 2020 06:14:43 -0700 (PDT) Received: from localhost.localdomain ([194.230.155.225]) by smtp.gmail.com with ESMTPSA id r4sm2825862wro.32.2020.05.27.06.14.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 06:14:43 -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> From: Emanuele Giuseppe Esposito Message-ID: <6a754b40-b148-867d-071d-8f31c5c0d172@redhat.com> Date: Wed, 27 May 2020 15:14:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200526153128.448bfb43@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; format=flowed 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: 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, Paolo Bonzini , 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" >> >> The file system is mounted on /sys/kernel/stats and would be already used >> by kvm. Statsfs was initially introduced by Paolo Bonzini [1]. > > What's the direct motivation for this work? Moving KVM stats out of > debugfs? There's many reasons: one of these is not using debugfs for statistics, but also (and mainly) to try and have a single tool that automatically takes care and displays them, instead of leaving each subsystem "on its own". Sure, everyone gathers and processes stats in different ways, and the aim of this tool is to hopefully be extensible enough to cover all needs. > In my experience stats belong in the API used for creating/enumerating > objects, statsfs sounds like going in the exact opposite direction - > creating a parallel structure / hierarchy for exposing stats. I know > nothing about KVM but are you sure all the info that has to be exposed > will be stats?I don't understand, what do you mean here? > > In case of networking we have the basic stats in sysfs, under the > netdevice's kobject. But since we're not using sysfs much any more > for config, new stats are added in netlink APIs. Again - same APIs > used for enumeration and config. I don't really know a lot about the networking subsystem, and as it was pointed out in another email on patch 7 by Andrew, networking needs to atomically gather and display statistics in order to make them consistent, and currently this is not supported by stats_fs but could be added in future. In addition, right now it won't work properly if the networking namespaces are enabled. That is another issue to take into consideration. That's also why I marked patch 7 as "not for merge" Regarding the config, as I said the idea is to gather multiple subsystems' statistics, therefore there wouldn't be a single configuration method like in netlink. For example in kvm there are file descriptors for configuration, and creating them requires no privilege, contrary to the network interfaces. Thank you, Emanuele 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 090D1C433DF for ; Wed, 27 May 2020 13:14:54 +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 D2959208DB for ; Wed, 27 May 2020 13:14:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ACEZHsqB"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RQBhO4Ry" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D2959208DB 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-Type: Content-Transfer-Encoding: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=4Fv3OJSc0taj1O5EVnNtBnwZ90GAa3h7i0sa1Kl6f8Y=; b=ACEZHsqBK0S7kNUcGLHI6jSrq V0vXRgtvHtZ+xDfh8g1ct5Js0z+2yv9SetjHLes7cx29r0JKFhG5xzNWBbR2nJKztoUbaXRjlv5XE TKOU6jcpJ5eRAWkcBqX5rUpZ0wQgl4wVdujCD+lAf5XaGH60HPNVtCBPAo8jO/PQL5meMgb6PdJmd jmbAZQkW27JobQ/3GgquFwdnZkFKN9gd7IaVUSylDLEhgJAz8nDSvsjrLOM2W0Scera7guuM7efaF Ixzg/Y7BQLzz6jCaSIM1jxMW2CYSwYij2m+IAsBnn2MwY17+qERz5dftxwSv7zFi9BK+VTg4c7C8l XWz+BHM0w==; 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 1jdvtV-0000ig-8h; Wed, 27 May 2020 13:14:53 +0000 Received: from us-smtp-1.mimecast.com ([207.211.31.81] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jdvtR-0000gN-IV for linux-arm-kernel@lists.infradead.org; Wed, 27 May 2020 13:14:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590585287; 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=Xp4IU27b7aXZqohMpJFZPawUcolyfH/CQm0FvETLmFY=; b=RQBhO4RyGmtftVuECLdSRL1cootwbRQuswQ9bmUojLtEP0hcYVKcfwIYJR3HFuiPa0dw74 W+xmaI1rR7U8qA+AYSbA/S0Ghg+1xtx8ZShdNuF0LheUsv+Ofhh55aJdphDb72G407fKVR 6o8ftQ4DdCK+nT3IF1xpTWcyXe2a57Q= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-205-dAOgQlVCNAajn3mY5ZFX5g-1; Wed, 27 May 2020 09:14:45 -0400 X-MC-Unique: dAOgQlVCNAajn3mY5ZFX5g-1 Received: by mail-wm1-f71.google.com with SMTP id l26so836552wmh.3 for ; Wed, 27 May 2020 06:14:45 -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=Xp4IU27b7aXZqohMpJFZPawUcolyfH/CQm0FvETLmFY=; b=N3W8eSIQd32gBunxqJ7GbmhmDbq4Ip9qUCj10sBhiLBpSrCanJUe/P/Fuc9VQvnW+X +Z10qEQRZdKFveh5IlOTbw8NpOAjZcWoDWBbgxv0gD6y7OQJ3aoFCzGNQS1XCvpfidth KJ9hVFm38yY5Zn44QbhIg0gjjxo0W3GXUJz8Y2LBGG1iOYbEX777bPjiKO96vwhoTdIT fSwv1Xya8WyEjdHAxszzZEeWhUh7wnc/x94Q4Cze0A+ELJ2L7GAOvSYFK47C8LJD2Ib7 /G6j56Vaveh63beUqZyknhUu1HZaygfgzsX3yACibIvH6UlnTTwHjPPlJWkUPi7FwFYm PV6A== X-Gm-Message-State: AOAM532thot8xBQKWdiMqVSwW8CpJYmyaUYRrfq7gMoRVCi4dfVzUMZv 1QXunN+924HzoVUzw/A/CMbFA/GUPrCwIX9z6+bH/dY+RNAVnAEsKgtDaCJp9KJRBmUvjZo/siy 3gN1vqjyrTNHfjg957TrDbecC8WurSYTaaEw= X-Received: by 2002:a1c:1b17:: with SMTP id b23mr4189520wmb.3.1590585284190; Wed, 27 May 2020 06:14:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXDD9pd6xDx85wKJ6DSUd0+jHdsTLXsbOgS1BfL3siVJ+UTokB2SEyRQkeYWpyFjB2Klsulg== X-Received: by 2002:a1c:1b17:: with SMTP id b23mr4189496wmb.3.1590585283890; Wed, 27 May 2020 06:14:43 -0700 (PDT) Received: from localhost.localdomain ([194.230.155.225]) by smtp.gmail.com with ESMTPSA id r4sm2825862wro.32.2020.05.27.06.14.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 06:14:43 -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> From: Emanuele Giuseppe Esposito Message-ID: <6a754b40-b148-867d-071d-8f31c5c0d172@redhat.com> Date: Wed, 27 May 2020 15:14:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200526153128.448bfb43@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_061449_691888_990F03F8 X-CRM114-Status: GOOD ( 17.56 ) 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: 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, Paolo Bonzini , linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Jim Mattson Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org >> >> The file system is mounted on /sys/kernel/stats and would be already used >> by kvm. Statsfs was initially introduced by Paolo Bonzini [1]. > > What's the direct motivation for this work? Moving KVM stats out of > debugfs? There's many reasons: one of these is not using debugfs for statistics, but also (and mainly) to try and have a single tool that automatically takes care and displays them, instead of leaving each subsystem "on its own". Sure, everyone gathers and processes stats in different ways, and the aim of this tool is to hopefully be extensible enough to cover all needs. > In my experience stats belong in the API used for creating/enumerating > objects, statsfs sounds like going in the exact opposite direction - > creating a parallel structure / hierarchy for exposing stats. I know > nothing about KVM but are you sure all the info that has to be exposed > will be stats?I don't understand, what do you mean here? > > In case of networking we have the basic stats in sysfs, under the > netdevice's kobject. But since we're not using sysfs much any more > for config, new stats are added in netlink APIs. Again - same APIs > used for enumeration and config. I don't really know a lot about the networking subsystem, and as it was pointed out in another email on patch 7 by Andrew, networking needs to atomically gather and display statistics in order to make them consistent, and currently this is not supported by stats_fs but could be added in future. In addition, right now it won't work properly if the networking namespaces are enabled. That is another issue to take into consideration. That's also why I marked patch 7 as "not for merge" Regarding the config, as I said the idea is to gather multiple subsystems' statistics, therefore there wouldn't be a single configuration method like in netlink. For example in kvm there are file descriptors for configuration, and creating them requires no privilege, contrary to the network interfaces. Thank you, Emanuele _______________________________________________ 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: Emanuele Giuseppe Esposito Date: Wed, 27 May 2020 13:14:41 +0000 Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics Message-Id: <6a754b40-b148-867d-071d-8f31c5c0d172@redhat.com> List-Id: References: <20200526110318.69006-1-eesposit@redhat.com> <20200526153128.448bfb43@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> In-Reply-To: <20200526153128.448bfb43@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: kvm@vger.kernel.org, Christian Borntraeger , Paolo Bonzini , 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 >> >> The file system is mounted on /sys/kernel/stats and would be already used >> by kvm. Statsfs was initially introduced by Paolo Bonzini [1]. > > What's the direct motivation for this work? Moving KVM stats out of > debugfs? There's many reasons: one of these is not using debugfs for statistics, but also (and mainly) to try and have a single tool that automatically takes care and displays them, instead of leaving each subsystem "on its own". Sure, everyone gathers and processes stats in different ways, and the aim of this tool is to hopefully be extensible enough to cover all needs. > In my experience stats belong in the API used for creating/enumerating > objects, statsfs sounds like going in the exact opposite direction - > creating a parallel structure / hierarchy for exposing stats. I know > nothing about KVM but are you sure all the info that has to be exposed > will be stats?I don't understand, what do you mean here? > > In case of networking we have the basic stats in sysfs, under the > netdevice's kobject. But since we're not using sysfs much any more > for config, new stats are added in netlink APIs. Again - same APIs > used for enumeration and config. I don't really know a lot about the networking subsystem, and as it was pointed out in another email on patch 7 by Andrew, networking needs to atomically gather and display statistics in order to make them consistent, and currently this is not supported by stats_fs but could be added in future. In addition, right now it won't work properly if the networking namespaces are enabled. That is another issue to take into consideration. That's also why I marked patch 7 as "not for merge" Regarding the config, as I said the idea is to gather multiple subsystems' statistics, therefore there wouldn't be a single configuration method like in netlink. For example in kvm there are file descriptors for configuration, and creating them requires no privilege, contrary to the network interfaces. Thank you, Emanuele