From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com ([207.211.31.81]:22282 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2389430AbgE0PAv (ORCPT ); Wed, 27 May 2020 11:00:51 -0400 Received: by mail-ed1-f72.google.com with SMTP id s14so2244958edr.7 for ; Wed, 27 May 2020 08:00:46 -0700 (PDT) Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics References: <20200526110318.69006-1-eesposit@redhat.com> <20200526153128.448bfb43@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <6a754b40-b148-867d-071d-8f31c5c0d172@redhat.com> <20200527133309.GC793752@lunn.ch> From: Paolo Bonzini Message-ID: Date: Wed, 27 May 2020 17:00:41 +0200 MIME-Version: 1.0 In-Reply-To: <20200527133309.GC793752@lunn.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-s390-owner@vger.kernel.org List-ID: To: Andrew Lunn , Emanuele Giuseppe Esposito Cc: Jakub Kicinski , 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 On 27/05/20 15:33, Andrew Lunn wrote: >> 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. > > Do you have any idea how you will support atomic access? It does not > seem easy to implement in a filesystem based model. Hi Andrew, there are plans to support binary access. Emanuele and I don't really have a plan for how to implement it, but there are developers from Google that have ideas (because Google has a similar "metricfs" thing in-house). I think atomic access would use some kind of "source_ops" struct containing create_snapshot and release_snapshot function pointers. Paolo