On Thu, Aug 27, 2015 at 05:09:21PM +0200, Thomas Gleixner wrote: > On Thu, 27 Aug 2015, Steven Rostedt wrote: > > On Thu, 27 Aug 2015 15:18:49 +0200 > > Frederic Weisbecker <fweis...@gmail.com> 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.
Sure it shouldn't really hurt anyway, since the presense of elapsing timers itself is checked locklessly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
