From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754912AbcHVMUN (ORCPT ); Mon, 22 Aug 2016 08:20:13 -0400 Received: from mail.osadl.at ([92.243.35.153]:43705 "EHLO mail.osadl.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbcHVMUM (ORCPT ); Mon, 22 Aug 2016 08:20:12 -0400 Date: Mon, 22 Aug 2016 12:19:49 +0000 From: Nicholas Mc Guire To: "Paul E. McKenney" Cc: Nicholas Mc Guire , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] rcuperf: make timeout HZ independent Message-ID: <20160822121949.GA26136@osadl.at> References: <1471864865-28040-1-git-send-email-hofrat@osadl.org> <20160822114943.GY3482@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160822114943.GY3482@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 22, 2016 at 04:49:43AM -0700, Paul E. McKenney wrote: > On Mon, Aug 22, 2016 at 01:21:05PM +0200, Nicholas Mc Guire wrote: > > Make the probability of ftrace dump not interfering with other writers > > grace period, HZ independent. > > > > Signed-off-by: Nicholas Mc Guire > > What we would -really- like is to vary the time based on the clock rate > of the CPUs (could use bogomips, I suppose) and the memory latency of > the system, so that systems with smaller memory latency and faster CPUs > would use shorter timeouts. However, slower CPUs tend to use smaller > HZ values, so varying based on HZ is not entirely insane. > > But what would you suggest? so what you want is a rough estimate of a "fixed instruction quantum" while bogomips/cpu_khz would ignore memory latency it might still be better than a fixed time then - something like schedule_timeout(msecs_to_jiffies(10000/cpu_khz)); ? > > Good question on schedule_timeout_interruptible()... I usually do that > if there is some reason to be sensitive to an early wakeup, for example, > to allow shutdown to proceed quickly, but that doesn't make much sense > here, given that ftrace_dump() is likely to take a very long time. > ok - just though that I was overlooking something - thanks for the clarification. thx! hofrat