From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id B9262DDF33 for ; Thu, 12 Mar 2009 08:00:19 +1100 (EST) Message-ID: <49B82657.9050709@freescale.com> Date: Wed, 11 Mar 2009 16:00:07 -0500 From: Scott Wood MIME-Version: 1.0 To: Timur Tabi Subject: Re: [PATCH v5] introduce macro spin_event_timeout() References: <1236723118-3577-1-git-send-email-timur@freescale.com> <49B6EAA4.9000803@freescale.com> <20090310223753.GB26415@zod.rchland.ibm.com> <1236729551.7086.26.camel@pasglop> <49B7EC27.3030305@freescale.com> <49B80F7F.30705@freescale.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Cc: linuxppc-dev@ozlabs.org, Roland Dreier List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Timur Tabi wrote: > On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood wrote: > >> I was under the impression that we were only talking about timeouts, and >> that the common case was significantly shorter than that. > > I think one of the concerns that Alan Cox raised is that the existence > of this macro would encourage people to spin for long durations. Yes, and I've already stated my response to that line of thinking. I just don't see anyone who would have done something better than a spin loop changing their mind because doing a spin loop becomes a little easier -- the spin loop is *already* easier than the alternatives. What if another variant were added that did msleep between iterations, for longer expected completion times? Or if we want to be really fancy, combine them into one function that starts with small udelays, then switches to msleep of progressively larger intervals up to some maximum? >> If it's atomic because preemption was disabled, yes -- but even a rare >> extended spin in such a context would be bad for hard realtime. If >> interrupts are disabled, or the code is executing from a timer interrupt (or >> possibly other interrupts depending on the hardware and its priority >> scheme), no. > > So in that case, I can't rely on jiffies. Or you can say that atomic context is outside the scope of this macro. -Scott