Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2191992ybi; Sat, 13 Jul 2019 08:44:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqzq+zedYlLLszx3Q+Dpxzs88UaomWqk2tlPGTXftRcOdCetjX5CfhLxUkTQUgdSPU35HraZ X-Received: by 2002:a63:455c:: with SMTP id u28mr17966914pgk.416.1563032652873; Sat, 13 Jul 2019 08:44:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563032652; cv=none; d=google.com; s=arc-20160816; b=SBnZ0wFWiKrgIowkDFjIOH8+JoHYnCnik/T6pNK+77ItBb6i9JiY15OyWM+NmkpPe0 aEXo8QRVhBI3SGyDe0XEtSG8pcNXS4Z7NgDyD7Cy9ePrUUwqa+djhZwjsOB1yF0xLmZl o/3nTIZdFs9WgcBlJL/XNiVvWspvbxZBohtc7dAlXFfbYY1Kt1F5//x4t6HeEsQSKwQn t3HRchXKyvyLC3mWj+uYIMDHwB6ybn/tGzkLjEaX2JN69VapVLOzARI3xF7yDrFWjp+F a6xDJkF/XFp1/YIASb/qbl9MLbEu74T2zHSjQI2WmqF6I0cCR9aQ+PsxoFTaz17Ke5Yn RSwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=38aEeWzt3ijYt2DwkFWv2RP5UO7sSKFkj7x22Iz0ST8=; b=g0AHeZgTyGKHQgvj89iiuLdbnl157EEp/BGxdbzofhOh4reAYX7qhZKsNHADUU8XFW hq6aZZon+rwN2TKBzgcIY0S+j40AzmTcLydiMowGNcjJmtDrH1wAeJWJbqst5lZO4cwO L++xfxrL27TSngEQHME+fBMue4pCnF3C9U18+0UpHScmmQVDX15s2WiRwvF3aPC5xjYD a25Q2KpTNoeDajZjuR1EWjiyyYeuOKcaOdKBvtUQ0K/VBoz21OUhIXr0gE9slONbSS7v WZT1ttARUCTDrVTM8axqVId8MaEc9yHq8ORfGu15hfooWuOrvDlXJnFZI/JKvfwubiJ9 Mrkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="x/SzQTNQ"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s18si10615535plp.128.2019.07.13.08.43.56; Sat, 13 Jul 2019 08:44:12 -0700 (PDT) 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=@joelfernandes.org header.s=google header.b="x/SzQTNQ"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727918AbfGMPnA (ORCPT + 99 others); Sat, 13 Jul 2019 11:43:00 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:39138 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727626AbfGMPnA (ORCPT ); Sat, 13 Jul 2019 11:43:00 -0400 Received: by mail-pg1-f194.google.com with SMTP id u17so5837190pgi.6 for ; Sat, 13 Jul 2019 08:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=38aEeWzt3ijYt2DwkFWv2RP5UO7sSKFkj7x22Iz0ST8=; b=x/SzQTNQ4sByXI7Io+rDMT15SeWxge0saa6QHsu4zEVm/KMxgPeKe7Gc44duVSyYxW 08LY05sma2GOurKLHzQ5q175aAd3uEhs2N4epWdcXEipUWGzyaV++4QUM2PemEyZwh8p fNpiLdMImxFOJTiyzUIshMIhAxA1gpajVgd90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=38aEeWzt3ijYt2DwkFWv2RP5UO7sSKFkj7x22Iz0ST8=; b=MpotMHNx0HFjEEDRIiuU2EKsKLYM56bDeX/bUw+VQTNOURbrM6slY/7Zwuu6fJFRbo K6jfghGPAjurc/DXEkSY66iz2Lf+aH0+9mmEwBM+I/d+bQRHKJo6O2+9oEp9qARV4jUB hGjrjCFzU6jpCy5QFjJvy1eGx13FyBTUL978KTkNTU3YuYzEHwgeSlgzKmUnCbNByaRM EmO7vtH3Bkf8NrMHan140LBdtI9iRzIMq5DkrM6FumdsblBm9tUOndSBTKfcWOPYOAa+ xHsXhTBwL6X4mrYarCQU+Qd98B7nn0kqTIpij5YSKnaeD9b8S+0aTXdERhPQQWOiMsAW Lnwg== X-Gm-Message-State: APjAAAVnJ+S74aJ1Tnb3JVImRO2xSCzH07QGfzTW9zVaTvmgRa2KsVYi CflaPvXEJPlNzgu44FB0juA= X-Received: by 2002:a65:5888:: with SMTP id d8mr17113350pgu.124.1563032579443; Sat, 13 Jul 2019 08:42:59 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id z19sm10488216pgv.35.2019.07.13.08.42.58 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 13 Jul 2019 08:42:58 -0700 (PDT) Date: Sat, 13 Jul 2019 11:42:57 -0400 From: Joel Fernandes To: "Paul E. McKenney" Cc: Byungchul Park , Byungchul Park , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , rcu , LKML , kernel-team@lge.com Subject: Re: [PATCH] rcu: Make jiffies_till_sched_qs writable Message-ID: <20190713154257.GE133650@google.com> References: <20190711123052.GI26519@linux.ibm.com> <20190711130849.GA212044@google.com> <20190711150215.GK26519@linux.ibm.com> <20190711164818.GA260447@google.com> <20190711195839.GA163275@google.com> <20190712063240.GD7702@X58A-UD3R> <20190712125116.GB92297@google.com> <20190713151330.GE26519@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190713151330.GE26519@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 13, 2019 at 08:13:30AM -0700, Paul E. McKenney wrote: > On Sat, Jul 13, 2019 at 10:20:02AM -0400, Joel Fernandes wrote: > > On Sat, Jul 13, 2019 at 4:47 AM Byungchul Park > > wrote: > > > > > > On Fri, Jul 12, 2019 at 9:51 PM Joel Fernandes wrote: > > > > > > > > On Fri, Jul 12, 2019 at 03:32:40PM +0900, Byungchul Park wrote: > > > > > On Thu, Jul 11, 2019 at 03:58:39PM -0400, Joel Fernandes wrote: > > > > > > Hmm, speaking of grace period durations, it seems to me the maximum grace > > > > > > period ever is recorded in rcu_state.gp_max. However it is not read from > > > > > > anywhere. > > > > > > > > > > > > Any idea why it was added but not used? > > > > > > > > > > > > I am interested in dumping this value just for fun, and seeing what I get. > > > > > > > > > > > > I wonder also it is useful to dump it in rcutorture/rcuperf to find any > > > > > > issues, or even expose it in sys/proc fs to see what worst case grace periods > > > > > > look like. > > > > > > > > > > Hi, > > > > > > > > > > commit ae91aa0adb14dc33114d566feca2f7cb7a96b8b7 > > > > > rcu: Remove debugfs tracing > > > > > > > > > > removed all debugfs tracing, gp_max also included. > > > > > > > > > > And you sounds great. And even looks not that hard to add it like, > > > > > > > > > > :) > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > > > index ad9dc86..86095ff 100644 > > > > > --- a/kernel/rcu/tree.c > > > > > +++ b/kernel/rcu/tree.c > > > > > @@ -1658,8 +1658,10 @@ static void rcu_gp_cleanup(void) > > > > > raw_spin_lock_irq_rcu_node(rnp); > > > > > rcu_state.gp_end = jiffies; > > > > > gp_duration = rcu_state.gp_end - rcu_state.gp_start; > > > > > - if (gp_duration > rcu_state.gp_max) > > > > > + if (gp_duration > rcu_state.gp_max) { > > > > > rcu_state.gp_max = gp_duration; > > > > > + trace_rcu_grace_period(something something); > > > > > + } > > > > > > > > Yes, that makes sense. But I think it is much better off as a readable value > > > > from a virtual fs. The drawback of tracing for this sort of thing are: > > > > - Tracing will only catch it if tracing is on > > > > - Tracing data can be lost if too many events, then no one has a clue what > > > > the max gp time is. > > > > - The data is already available in rcu_state::gp_max so copying it into the > > > > trace buffer seems a bit pointless IMHO > > > > - It is a lot easier on ones eyes to process a single counter than process > > > > heaps of traces. > > > > > > > > I think a minimal set of RCU counters exposed to /proc or /sys should not > > > > hurt and could do more good than not. The scheduler already does this for > > > > scheduler statistics. I have seen Peter complain a lot about new tracepoints > > > > but not much (or never) about new statistics. > > > > > > > > Tracing has its strengths but may not apply well here IMO. I think a counter > > > > like this could be useful for tuning of things like the jiffies_*_sched_qs, > > > > the stall timeouts and also any other RCU knobs. What do you think? > > > > > > I prefer proc/sys knob for it to tracepoint. Why I've considered it is just it > > > looks like undoing what Paul did at ae91aa0ad. > > > > > > I think you're rational enough. I just wondered how Paul think of it. > > > > I believe at least initially, a set of statistics can be made > > available only when rcutorture or rcuperf module is loaded. That way > > they are purely only for debugging and nothing needs to be exposed to > > normal kernels distributed thus reducing testability concerns. > > > > rcu_state::gp_max would be trivial to expose through this, but for > > other statistics that are more complicated - perhaps > > tracepoint_probe_register can be used to add hooks on to the > > tracepoints and generate statistics from them. Again the registration > > of the probe and the probe handler itself would all be in > > rcutorture/rcuperf test code and not a part of the kernel proper. > > Thoughts? > > It still feels like you guys are hyperfocusing on this one particular > knob. I instead need you to look at the interrelating knobs as a group. Thanks for the hints, we'll do that. > On the debugging side, suppose someone gives you an RCU bug report. > What information will you need? How can you best get that information > without excessive numbers of over-and-back interactions with the guy > reporting the bug? As part of this last question, what information is > normally supplied with the bug? Alternatively, what information are > bug reporters normally expected to provide when asked? I suppose I could dig out some of our Android bug reports of the past where there were RCU issues but if there's any fires you are currently fighting do send it our way as debugging homework ;-) thanks, - Joel