Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp543804ybf; Wed, 26 Feb 2020 18:11:51 -0800 (PST) X-Google-Smtp-Source: APXvYqzeCqchtxEFJDjOgDns4Ng5pe1D/GZ78npe30VrGtX2LaPMxid/2+env4Rru6Ug7oymtBlL X-Received: by 2002:aca:3f43:: with SMTP id m64mr1518447oia.165.1582769511489; Wed, 26 Feb 2020 18:11:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582769511; cv=none; d=google.com; s=arc-20160816; b=mqMMeyNss0uDXJBj34GxGlq+m5AAuZjb59TBmcvawQnGWxb6PzUPQyc5Fx2sqBw7fq 8rg4a2WId1QDnA8xTi4ngW8yvDM08Rg1baS7lLDXVDAP6h7DudgPQrPBLQdxw4nZarKg B4rF59iCzVop3z8QKP2ffSLw/GuUlBDAej01pdZd+ox7AwtTxV02d94aAOz81LsakGV9 gzLGg9bnnbsAvMJljqPmLiY9p49B90jZk5zbQDNOCV13Lydn7cLDA7mjfp8BERw21JEd G3uK85rNaVs9Fodoc0yN+SLKbKhvlZJJVRMaAQhhGFZo5BmZti6JpF8n/BF2oy7JKnvf ELHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=Z3j3qOSE0hSYUuarsEB4aqCiwohHy19qA76Ijg0+PjQ=; b=jcrc6LpYrgSbmhOtBbopFVY50M3zR21y7u4kjiea4hJj5YZl490ol1CyiR6WlHB6OS GDbQrmHoHrpnu2JlzVGQSp/rsQlexLwfRl7SVjqASfUasiJ//2GA+4GlNC5i/fWPdK0Y zPI26ei0cDrMb+ip4w9XDAimyXw/XxBajG0sdd3FD8Y42giqgpepsK1rmo6DC/CP19DB s16y2mkQrmvor8HIXE3FFa4HLKEqGtBg50Do0+VrPl2Ytwb2SHcmiHiMwFus9FWYhbo3 xdwXw3jE3kw1IWIEgjb4UXQUsuuZX91yi1zbn0AQTBsYPNBBVFOs1cmXXEscPSkumaM4 rPpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AUDGnGUk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f20si578346otl.313.2020.02.26.18.11.36; Wed, 26 Feb 2020 18:11:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AUDGnGUk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728299AbgB0CK0 (ORCPT + 99 others); Wed, 26 Feb 2020 21:10:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:36048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728178AbgB0CK0 (ORCPT ); Wed, 26 Feb 2020 21:10:26 -0500 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C95DB24650; Thu, 27 Feb 2020 02:10:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582769425; bh=4TGbWFlb9eTmYavHQrRR7TlW2bK12n9BSdFbsu7RxTM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AUDGnGUk3IasFzMYsELzN30dhiYuwHtsgzarpY0O+UJ4tDitHWo8NunYJzrXmepHy MNwew2+cFM7VI6WJ0BK+HZiVPNmPp6iwoUtWLGSdVElSB4Q1cKnnBojIKnhLou/mCI 1CdFLN/gHddBO1T/ACjCA8VOzyJn62YDlMZ7+3zA= Date: Thu, 27 Feb 2020 11:10:19 +0900 From: Masami Hiramatsu To: Luigi Rizzo Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Masami Hiramatsu , Andrew Morton , Greg KH , naveen.n.rao@linux.ibm.com, ardb@kernel.org, Luigi Rizzo , Paolo Abeni , giuseppe.lettieri@unipi.it, Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , Jesper Dangaard Brouer , mingo@redhat.com, acme@kernel.org, Steven Rostedt Subject: Re: [PATCH v2 1/2] kstats: kernel metric collector Message-Id: <20200227111019.8fd6f57819282a08ced3ce35@kernel.org> In-Reply-To: References: <20200226134637.31670-1-lrizzo@google.com> <20200226134637.31670-2-lrizzo@google.com> <20200226161941.GZ18400@hirez.programming.kicks-ass.net> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Luigi, On Wed, 26 Feb 2020 11:31:01 -0800 Luigi Rizzo wrote: > On Wed, Feb 26, 2020 at 8:19 AM Peter Zijlstra wrote: > > > > On Wed, Feb 26, 2020 at 05:46:36AM -0800, Luigi Rizzo wrote: > > > kstats is a helper to accumulate in-kernel metrics (timestamps, sizes, > > > etc.) and show distributions through debugfs. > > > Set CONFIG_KSTATS=m or y to enable it. > > > > > > Creating a metric takes one line of code (and one to destroy it): > > > > > > struct kstats *key = kstats_new("foo", 3 /* frac_bits */); > > > ... > > > kstats_delete(key); > > > > > > The following line records a u64 sample: > > > > > > kstats_record(key, value); > > > > > > kstats_record() is cheap (5ns hot cache, 250ns cold cache). Samples are > > > accumulated in a per-cpu array with 2^frac_bits slots for each power > > > of 2. Using frac_bits = 3 gives about 30 slots per decade. > > > > So I think everybody + dog has written code like this, although I never > > bothered with the log2 based buckets myself. Nor have I ever bothered > > with doing a debugfs interface. > > the above is perhaps one excellent argument to why it may deserve to be in: > so that people don't need to write the measurement code time and again, > or, as I have done myself multiple times, use some inferior hack (racy > counter, coarse buckets) or give up measuring things and rely on guessing. > > > I find it very hard to convince myself something like this deserves to > > live upstream, vs. remaining in the local debug/hack toolbox. > > > > Tracing has an aggregator (histogram), you can dump the raw deltas, or > > you can hack up a custom aggregator in a few lines, or you do BPF if > > you're so inclined. > > And this is possibly another good argument: sometimes the systems where it > would be interesting to collect data are not accessible to the developers with > skills to write the monitoring code and run a modified kernel. Would you mean the histogram requires more skills to use it? I think Peter's point is that there is already an "ability" and "interface" to do that in kenrel. If you think that is not easy to use, can you modify existing features or add a user tool to use it easier? Thank you, -- Masami Hiramatsu