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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 4E516C48BDF for ; Tue, 15 Jun 2021 08:38:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30D5361413 for ; Tue, 15 Jun 2021 08:38:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231162AbhFOIkF (ORCPT ); Tue, 15 Jun 2021 04:40:05 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:44815 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230332AbhFOIkD (ORCPT ); Tue, 15 Jun 2021 04:40:03 -0400 Received: from [192.168.1.155] ([95.115.9.120]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MYcy3-1lpPX61RGl-00VeCh; Tue, 15 Jun 2021 10:37:39 +0200 Subject: Re: [PATCH v9 0/5] KVM statistics data fd-based binary interface To: Jing Zhang , KVM , KVMARM , LinuxMIPS , KVMPPC , LinuxS390 , Linuxkselftest , Paolo Bonzini , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Will Deacon , Huacai Chen , Aleksandar Markovic , Thomas Bogendoerfer , Paul Mackerras , Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Peter Shier , Oliver Upton , David Rientjes , Emanuele Giuseppe Esposito , David Matlack , Ricardo Koller , Krish Sadhukhan , Fuad Tabba References: <20210614212155.1670777-1-jingzhangos@google.com> From: "Enrico Weigelt, metux IT consult" Message-ID: Date: Tue, 15 Jun 2021 10:37:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210614212155.1670777-1-jingzhangos@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: tl Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:Vod45xLxHxZ5p8qYKvuWym3LEAiarmlv0Xbt34OpNBV9uy1sBdE IRftON+oudc8QVSK3OpycOl49aHJfySAgkANRqrTI39LcdQIXpjA7mxltjpeNzUcQSldpbN 9MatQnRvvRMJJ8elPHcd2BkxKXtnpLxALuiGllUwQeIJ/pSfjl/1Ju+2MmxGm86GlBu1W06 ZMtU7WHK45h2IdXcp/e8g== X-UI-Out-Filterresults: notjunk:1;V03:K0:+53FXRRHLqc=:mz+uz7bhnpeydAZf0N2025 PzwGuvUWyPVQfHIrPDNsiRUyENR8k8pU+IrQTGZS1wnh9dAW8iuHrnc1m2pJ3oMjaQSkDQfYE CitMcMEor434oAPJQjN+scqfRgySjAt2AMJpYyCkXEnjuNLL435UQVMezynLHSeRwuZ3mbYhv wwNIBxhtwjP7SVCR9sHWQMJzG+1zH/4+qxGxAb9sDf80fkBI07uRQz5xuvmLVq7WGoWF74/Us BQiBgnydw4wY4V1J5Y5yEAwuoKhnbDEyPZHgJvQT1w1FMWuELbaEz6VH6F+SXOPaAlywjQe7q WGTk8EjDeLtaCIS9fu2JoA0zWjjS4a4EEo684bMWJScBce+ezZ/9MV7YfgKmdb16Tr0FIJWya +bz0ZJ5j2y6JQlx5SiGGMEUCnQUBNS7Fm5VA0Sa3ZK1jXEY5/DPcdideck40Dn+2OPAZuXtU9 ESR5huX3pYZYRU/wFSEiLE4jZIbf867UrKIgkQCDL+90WY3iyjt/tICjAmssa+jDfqp5+UZuZ 2L9tw9OzjAAntKVmcEinnI= Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On 14.06.21 23:21, Jing Zhang wrote: Hi, > This patchset provides a file descriptor for every VM and VCPU to read > KVM statistics data in binary format. I've missed the discussions of previous versions, so please forgive my stupid questions: * why is it binary instead of text ? is it so very high volume that it really matters ? * how will possible future extensions of the telemetry packets work ? * aren't there other means to get this fd instead of an ioctl() on the VM fd ? something more from the outside (eg. sysfs/procfs) * how will that relate to other hypervisors ? Some notes from the operating perspective: In typical datacenters we've got various monitoring tools that are able to catch up lots of data from different sources (especially files). If an operator e.g. is interested in something in happening in some file (e.g. in /proc of /sys), it's quite trivial - just configure yet another probe (maybe some regex for parsing) and done. Automatically fed in his $monitoring_solution (e.g. nagios, ELK, Splunk, whatsnot) With your approach, it's not that simple: now the operator needs to create (and deploy and manage) a separate agent that somehow receives that fd from the VMM, reads and parses that specific binary stream and finally pushes it into the monitoring infrastructure. Or the VMM writes it into some file, where some monitoring agent can pick it up. In any case, not actually trivial from ops perspective. In general I tend to like the fd approach (even though I don't like ioctls very much - I'd rather like to have it more Plan9-like ;-)). But it has the drawback of acquiring those fd's by separate processes isn't entirely easy and needs a lot of coordinated interaction. That issue would be much easier if we had the ability to publish existing fd's into the file system (like Plan9's srvfs does), but we don't have that yet. (actually, I've hacked up some srvfs for Linux, but ... well ... it's just a hack, nowhere near to production). Why not putting this into sysfs ? I see two options: a) if it's really kvm-specific (and no chance of using the same interface for other hypervisors), we could put it under the kvm device (/sys/class/misc/kvm). b) have a generic VMM stats interface that theroretically could work with any hypervisor. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287