From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754781Ab0HZXiQ (ORCPT ); Thu, 26 Aug 2010 19:38:16 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:48548 "EHLO e1.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753297Ab0HZXiO (ORCPT ); Thu, 26 Aug 2010 19:38:14 -0400 Date: Thu, 26 Aug 2010 16:38:11 -0700 From: "Paul E. McKenney" To: Mathieu Desnoyers Cc: Thomas Gleixner , Peter Zijlstra , LKML , Linus Torvalds , Andrew Morton , Ingo Molnar , Steven Rostedt , Tony Lindgren , Mike Galbraith Subject: Re: [RFC PATCH 00/11] sched: CFS low-latency features Message-ID: <20100826233811.GM2367@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20100826180908.648103531@efficios.com> <1282849045.1975.1587.camel@laptop> <20100826231806.GK2367@linux.vnet.ibm.com> <20100826232858.GA28177@Krystal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100826232858.GA28177@Krystal> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 26, 2010 at 07:28:58PM -0400, Mathieu Desnoyers wrote: > * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote: > > On Fri, Aug 27, 2010 at 12:22:46AM +0200, Thomas Gleixner wrote: > > > On Thu, 26 Aug 2010, Thomas Gleixner wrote: > > > > On Thu, 26 Aug 2010, Peter Zijlstra wrote: > > > > > > > > > > Fudging fork seems dubious at best, it seems generated by the use of > > > > > timer_create(.evp->sigev_notify = SIGEV_THREAD), which is a really > > > > > broken thing to do, it has very ill defined semantics and is utterly > > > > > unable to properly cope with error cases. Furthermore its trivial to > > > > > actually correctly implement the desired behaviour, so I'm really > > > > > skeptical on this front; friends don't let friends use SIGEV_THREAD. > > > > > > > > SIGEV_THREAD is the best proof that the whole posix timer interface > > > > was comitte[e]d under the influence of not to be revealed > > > > mind-altering substances. > > > > > > > > I completely object to add timer specific wakeup magic and support for > > > > braindead fork orgies to the kernel proper. All that mess can be fixed > > > > in user space by using sensible functionality. > > > > > > > > Providing support for misdesigned crap just for POSIX compliance > > > > reasons and to make some of the blind abusers of that very same crap > > > > happy would be a completely stupid decision. > > > > > > > > In fact that would make a brilliant precedence case for forcing the > > > > kernel to solve user space madness at the expense of kernel > > > > complexity. If we follow down that road we get requests for extra > > > > functionality for AIO, networking and whatever in a split second with > > > > no real good reason to reject them anymore. > > > > > > I really risked eye cancer and digged into the glibc code. > > > > > > /* There is not much we can do if the allocation fails. */ > > > (void) pthread_create (&th, &tk->attr, timer_sigev_thread, td); > > > > > > So if the helper thread which gets the signal fails to create the > > > thread then everything is toast. > > > > > > What about fixing the f*cked up glibc implementation in the first place > > > instead of fiddling in the kernel to support this utter madness? > > > > > > WTF can't the damned delivery thread not be created when timer_create > > > is called and the signal be delivered to that very thread directly via > > > SIGEV_THREAD_ID ? > > > > C'mon, Thomas!!! That is entirely too sensible!!! ;-) > > > > But if you are going to create the thread at timer_create() time, > > why not just have the new thread block for the desired duration? > > The timer infrastructure allows things like periodic timer which restarts when > it fires, detection of missed timer events, etc. If you try doing this in a > userland thread context with a simple sleep, then your period becomes however > long you sleep for _and_ the thread execution time. This is all in all quite > different from the timer semantic. Hmmm... Why couldn't the thread in question set the next sleep time based on the timer period? Yes, if the function ran for longer than the period, there would be a delay, but the POSIX semantics allow such a delay, right? Thanx, Paul