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 S1754814AbcFTN66 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 20 Jun 2016 09:58:58 -0400
Received: from www.linutronix.de ([62.245.132.108]:60126 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752872AbcFTN6a (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 20 Jun 2016 09:58:30 -0400
Date: Mon, 20 Jun 2016 15:56:10 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Eric Dumazet <edumazet@google.com>
cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "Paul E. 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>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        George Spelvin <linux@sciencehorizons.net>,
        Len Brown <lenb@kernel.org>
Subject: Re: [patch V2 00/20] timer: Refactor the timer wheel
In-Reply-To: <CANn89iLoVRcO1quHnKLFhvt56Jwk3Rht+v0x7pKVoE=MXFJN-w@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1606201541000.5839@nanos>
References: <20160617121134.417319325@linutronix.de> <CANn89iKS03PKbT0Acvnn87g5pd8LmaoJQs3zjmByB2zrndENkw@mail.gmail.com> <alpine.DEB.2.11.1606171556200.5839@nanos> <CANn89iLoVRcO1quHnKLFhvt56Jwk3Rht+v0x7pKVoE=MXFJN-w@mail.gmail.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 17 Jun 2016, Eric Dumazet wrote:
> To avoid increasing probability of such events we would need to have
> at least 4 ms difference between the RTO timer and delack timer.
> 
> Meaning we have to increase both of them and increase P99 latencies of
> RPC workloads.
> 
> Maybe a switch to hrtimer would be less risky.
> But I do not know yet if it is doable without big performance penalty.

That will be a big performance issue. So we have the following choices:

1) Increase the wheel size for HZ=1000. Doable, but utter waste of space and
   obviously more pointless work when collecting expired timers.

2) Cut off at 37hrs for HZ=1000. We could make this configurable as a 1000HZ
   option so datacenter folks can use this and people who don't care and want
   better batching for power can use the 4ms thingy.

3) Split the wheel granularities. That would leave the first wheel with tick
   granularity and the next 3 with 12.5% worst case and then for the further
   out timers we'd switch to 25%.

Thoughts?

Thanks,

	tglx