linux-kernel - Re: [PATCH RFC] rcuperf: make timeout HZ independent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160822121949.GA26136@osadl.at>
Date:   Mon, 22 Aug 2016 12:19:49 +0000
From:   Nicholas Mc Guire <der.herr@...r.at>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Nicholas Mc Guire <hofrat@...dl.org>,
        Josh Triplett <josh@...htriplett.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] rcuperf: make timeout HZ independent

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 <hofrat@...dl.org>
> 
> 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