Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754079AbbH0PKK (ORCPT ); Thu, 27 Aug 2015 11:10:10 -0400 Received: from www.linutronix.de ([62.245.132.108]:59979 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752754AbbH0PKI (ORCPT ); Thu, 27 Aug 2015 11:10:08 -0400 Date: Thu, 27 Aug 2015 17:09:21 +0200 (CEST) From: Thomas Gleixner To: Steven Rostedt cc: Frederic Weisbecker , Hideaki Kimura , Jason Low , Oleg Nesterov , Andrew Morton , Peter Zijlstra , Ingo Molnar , "Paul E. McKenney" , linux-kernel@vger.kernel.org, Linus Torvalds , Rik van Riel , Scott J Norton Subject: Re: [PATCH 0/3] timer: Improve itimers scalability In-Reply-To: <20150827104707.6943c312@gandalf.local.home> Message-ID: References: <1440559068-29680-1-git-send-email-jason.low2@hp.com> <20150825202710.d960a928.akpm@linux-foundation.org> <1440606804.23728.85.camel@j-VirtualBox> <20150826170851.GA5264@redhat.com> <1440626847.23728.122.camel@j-VirtualBox> <55DE4366.9080104@hpe.com> <20150826231326.GE11992@lerouge> <55DE4FA8.7050701@hpe.com> <20150827131844.GB21105@lerouge> <20150827104707.6943c312@gandalf.local.home> 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: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1883 Lines: 42 On Thu, 27 Aug 2015, Steven Rostedt wrote: > On Thu, 27 Aug 2015 15:18:49 +0200 > Frederic Weisbecker wrote: > > > On Wed, Aug 26, 2015 at 04:45:44PM -0700, Hideaki Kimura wrote: > > > I totally agree that this is not a perfect solution. If there are 10x more > > > cores and sockets, just the atomic fetch_add might be too expensive. > > > > > > However, it's comparatively/realistically the best thing we can do without > > > any drawbacks. We can't magically force all library developers to write the > > > most scalable code always. > > > > > > My point is: this is a safety net, and a very effective one. > > > > I mean the problem here is that a library uses an unscalable profiling feature, > > unconditionally as soon as you load it without even initializing anything. And > > this library is used in production. > > > > At first sight, fixing that in the kernel is only a hack that just reduces a bit > > the symptoms. > > > > What is the technical issue that prevents from fixing that in the library itself? > > Posix timers can be attached anytime. > > I'm curious to what the downside of this patch set is? If we can fix a > problem that should be fixed in userspace, but does not harm the kernel > by doing so, is that bad? (an argument for kdbus? ;-) The patches are not fixing a problem which should be fixed in user space. They merily avoid lock contention which happens to be prominent with that particular library. But avoiding lock contention even for 2 threads is a worthwhile exercise if it does not hurt otherwise. And I can't see anything what hurts with these patches. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/