This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 26 18:13:27 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8IJD6X23844 for ; Wed, 18 Sep 2002 21:13:07 +0200 Received: (qmail 3176 invoked from network); 18 Sep 2002 07:33:34 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 18 Sep 2002 07:33:34 -0000 Received: (qmail 18549 invoked by uid 1000); 17 Sep 2002 21:16:58 -0000 Received: (maildatabase); juh Received: (qmail 29994 invoked by alias); 7 Feb 2002 20:54:49 -0000 Received: (qmail 29991 invoked from network); 7 Feb 2002 20:54:49 -0000 Received: from unknown (HELO dipsaus.ds9a.tudelft.nl) (::ffff:10.0.0.202) by spaans.ds9a.nl with SMTP; 7 Feb 2002 20:54:49 -0000 Received: (qmail 10498 invoked from network); 7 Feb 2002 20:53:50 -0000 Received: from unknown (HELO vger.kernel.org) (::ffff:12.107.208.194) by adsl-xs4all.ds9a.nl with SMTP; 7 Feb 2002 20:53:50 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 7 Feb 2002 15:51:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 7 Feb 2002 15:51:05 -0500 Received: from mail.epost.de ([64.39.38.71]:27039 "EHLO mail.epost.de") by vger.kernel.org with ESMTP id ; Thu, 7 Feb 2002 15:50:54 -0500 Received: from epost.de (212.144.142.91) by mail.epost.de (5.5.052) (authenticated as martin.wirth@epost.de) id 3C606F5400011B59; Thu, 7 Feb 2002 21:50:45 +0100 Message-Id: <3C62E871.4514B926@epost.de> Date: Thu, 07 Feb 2002 21:49:53 +0100 From: Martin Wirth Reply-To: martin.wirth@dlr.de X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en Mime-Version: 1.0 Cc: Robert Love , linux-kernel@vger.kernel.org, akpm@zip.com.au, mingo@elte.hu Subject: [RFC] New locking primitive for 2.5 References: <3C629F91.2869CB1F@dlr.de> <1013107259.10430.29.camel@phantasy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Spam-Status: No, hits=1.0 required=5.0 tests=TO_MALFORMED version=2.01 Lines: 79 Christoph Hellwig wrote: > I think this API is really ugly. If both pathes actually do the same, > just with different defaults, one lock function with a flag would be > much nicer. Just to use plain numbers is not very instructive, so you ask for a macro definition like COMBI_LOCK_SPIN_MODE ????? > Also why do we need two unlock functions? There is the generic_unlock function, if you forgot in which mode you are. The main reason is performance for the spin mode: combi_spin_unlock is just a spin_unlock, no test, no branch. So you are faster if you know what you did a few lines of code before ;-) Robert Love wrote: > > If a spin_lock request is blocked by a mutex_lock call, the spin_lock > > attempt also sleeps i.e. behaves like a semaphore. > > If you gained ownership of the lock, you can switch between spin-mode > > and mutex-(ie.e sleeping) mode by calling: > > This can be bad. What if I grab a spinlock in a codepath where only a > spinlock is appropriate (i.e. somewhere I can't sleep, like an irq > handler) -- and then I sleep? As noted in my initial e-mail the current implementation is not for use in irq-handlers or BHs etc. > > > Open questions: > > > > * Does it make sense to also provide irq-save versions of the > > locking functions? This means you could use the unlock functions > > from interrupt context. But the main use in this situation is > > completion handling and there are already (new) completion handlers > > available. So I don't think this is a must have > > You can't sleep in an interrupt request handler, so this wouldn't make a > lot of sense. You of course were only allowed to call the unlock() functions!! Therefore you could use them to free a resource from the handler (but that's very much completion handling, see above). > We shouldn't engage in wholesale changing of spinlocks to semaphores > without a priority-inheritance mechanism. And _that_ is the bigger > issue ... The combilock at least can be used to narrow the time windows for priority inversion because for most purposes you would use the spin mode. I thinking about some extension in this direction (that's why the owner field is a pointer to the owning task btw.). > As for combi lock itself, it would be great, if it were possible to > detect whether lock is held by thread running on the same CPU and sleep > if so. This would allow for implementing interrupts as separate threads, > etc. That the e.g. the aproach of Solaris which results in about 5 time higher latencies from a hardware interrupt to the waiting process. Martin Wirth - 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/