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 2EA83C47259 for ; Tue, 5 May 2020 17:02:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 03EB9206B9 for ; Tue, 5 May 2020 17:02:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MlVHtLTY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730654AbgEERCo (ORCPT ); Tue, 5 May 2020 13:02:44 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:51843 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730570AbgEERCl (ORCPT ); Tue, 5 May 2020 13:02:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588698159; 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=5wA5G//ZMwKX3KXqf3Mv3pq9KAcUMr/otngiqdWE/rQ=; b=MlVHtLTYs5c/qp4v+MUqKfkdu+gayo+YrOPdAPrqUH17h94GAYml7XE29etNbtWuddsCtW lHhOjlF5obhgRGHZImG+zNhOtOYCTCI2DKRDafbn3xN1h2wIaYHP7UseGYylGVXb7Hfr0K tuDvQuLf2c42QCOCcWHjvH9qAmLE45U= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-rCi-DIU-NrqjjSqDuv59CA-1; Tue, 05 May 2020 13:02:38 -0400 X-MC-Unique: rCi-DIU-NrqjjSqDuv59CA-1 Received: by mail-wr1-f70.google.com with SMTP id f2so1528889wrm.9 for ; Tue, 05 May 2020 10:02:37 -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=5wA5G//ZMwKX3KXqf3Mv3pq9KAcUMr/otngiqdWE/rQ=; b=C5ErChMINM7ju63DOgEHnm/rz396MjUcLqpFLbJTQvvISM77rhxxl9G82w0ox2/NkE I9lUE37f8RDvOXCAmqvez69qztclcGKzuRu3BKAztspSMTr12jcyRCK7pTNhoDLmR6lu zTxKNi1rNVW66O4skCHTJaJ9ue7TSClkghCoQFSrkzWCHnl+JiwgA9lnkzomv82lF/rd joMZ3GkFs9CBeNgaH16uqfNW09/3NusbMBaY21JrxPwC0h/TDPftZaMZAjQQqXve5a9j 8pOC2NtGTW+PuhdFynE2+9hZiRT/7B4MX9qyAV55UQleJ6JW9pW2FXueCWxbGKBeS2lF NZmg== X-Gm-Message-State: AGi0Pub0V9jTDpiO+zbp+92zlkC/c3W6dZMbpGCEt6r1j/jTcCWJOWwO EvMSKq4UOpeVZATUFSPqRK2pmINRpJ5Urz106MunehE/aVHo1sNLnJQIoTOq2RBe872fZypxQZz Dn/OY8gPZ6XAIYmI+07BrLGUJ X-Received: by 2002:adf:d0c5:: with SMTP id z5mr5096744wrh.410.1588698156792; Tue, 05 May 2020 10:02:36 -0700 (PDT) X-Google-Smtp-Source: APiQypJLNwomNOVHwIvpSDnSwZmv6Omr127dtUlNqUvacYqezIg5AT62IcLqVfdIy2Hep5WWyqsAoA== X-Received: by 2002:adf:d0c5:: with SMTP id z5mr5096701wrh.410.1588698156541; Tue, 05 May 2020 10:02:36 -0700 (PDT) Received: from [192.168.178.58] ([151.20.132.175]) by smtp.gmail.com with ESMTPSA id g24sm1632241wrb.35.2020.05.05.10.02.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 10:02:35 -0700 (PDT) Subject: Re: [PATCH v2 0/5] Statsfs: a new ram-based file sytem for Linux kernel statistics To: Jim Mattson , Emanuele Giuseppe Esposito Cc: David Rientjes , Jonathan Adams , kvm list , Christian Borntraeger , David Hildenbrand , Cornelia Huck , Vitaly Kuznetsov , Alexander Viro , Emanuele Giuseppe Esposito , LKML , linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Linux FS Devel References: <20200504110344.17560-1-eesposit@redhat.com> From: Paolo Bonzini Message-ID: <1d12f846-bf89-7b0a-5c71-e61d83b1a36f@redhat.com> Date: Tue, 5 May 2020 19:02:34 +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: 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 05/05/20 18:53, Jim Mattson wrote: >>> Since this is becoming a generic API (good!!), maybe we can discuss >>> possible ways to optimize gathering of stats in mass? >> Sure, the idea of a binary format was considered from the beginning in >> [1], and it can be done either together with the current filesystem, or >> as a replacement via different mount options. > > ASCII stats are not scalable. A binary format is definitely the way to go. I am totally in favor of having a binary format, but it should be introduced as a separate series on top of this one---and preferably by someone who has already put some thought into the problem (which Emanuele and I have not, beyond ensuring that the statsfs concept and API is flexible enough). ASCII stats are necessary for quick userspace consumption and for backwards compatibility with KVM debugfs (which is not an ABI, but it's damn useful and should not be dropped without providing something as handy), so this is what this series starts from. Paolo