From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754090AbcGVNGT (ORCPT <rfc822;w@1wt.eu>);
	Fri, 22 Jul 2016 09:06:19 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:36512 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753528AbcGVNGS (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 22 Jul 2016 09:06:18 -0400
Date: Fri, 22 Jul 2016 15:04:02 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>,
        Frederic Weisbecker <fweisbec@gmail.com>, Chris Mason <clm@fb.com>,
        Arjan van de Ven <arjan@infradead.org>, rt@linutronix.de,
        Rik van Riel <riel@redhat.com>,
        George Spelvin <linux@sciencehorizons.net>,
        Len Brown <lenb@kernel.org>, Josh Triplett <josh@joshtriplett.org>,
        Eric Dumazet <edumazet@google.com>
Subject: Re: [patch 4 15/22] timer: Remove slack leftovers
In-Reply-To: <CAHmME9ruBKmuLDxy4yx3cyR_btdBDP4Ps8bSUw+WDbeiatpasg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1607221453230.3906@nanos>
References: <20160704093956.299369787@linutronix.de> <20160704094342.189813118@linutronix.de> <CAHmME9ruBKmuLDxy4yx3cyR_btdBDP4Ps8bSUw+WDbeiatpasg@mail.gmail.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 22 Jul 2016, Jason A. Donenfeld wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> > We now have implicit batching in the timer wheel. The slack is not longer
> > used. Remove it.
> >From a brief look at timer.c, it looked like __mod_timer was rather
> expensive. So, as an optimization, I wanted the "timer_pending(timer)
> && timer->expires == expires" condition to be hit in most of the
> cases. I accomplished this by doing:
> 
>     set_timer_slack(timer, HZ / 4);
> 
> This ensured that we'd only wind up calling __mod_timer 4 times per
> second, at most.
>
> With the removal of the slack concept, I no longer can do this. I
> haven't reviewed this series in depth, but I'm wondering if you'd
> recommend a different optimization instead. Or, have things been

Well, this really depends on the TIMEOUT value you have. The code now does
implicit batching for larger timeouts by queueing the timers into wheels with
coarse grained granularity. As long as your new TIMEOUT value ends up in the
same bucket then that's equivalent to the slack thing.

Can you give me a ballpark of your TIMEOUT value?

> reworked so much, that calling mod_timer is now always inexpensive?

When you take the slow (queueing) path, it's still expensive, not as bad as
the previous one, but not really cheap either.

Thanks,

	tglx