From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: down_spin() implementation Date: Sat, 29 Mar 2008 00:48:21 +0100 Message-ID: <200803290048.22931.arnd@arndb.de> References: <1FE6DD409037234FAB833C420AA843ECE9DF60@orsmsx424.amr.corp.intel.com> <20080328124517.GQ16721@parisc-linux.org> <1FE6DD409037234FAB833C420AA843ECF237C0@orsmsx424.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1FE6DD409037234FAB833C420AA843ECF237C0-7XlYjKTK0pM64kNsxIetb7fspsVTdybXVpNB7YpNyf8@public.gmane.org> Content-Disposition: inline Sender: linux-arch-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: To: "Luck, Tony" Cc: Matthew Wilcox , Nick Piggin , Stephen Rothwell , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Friday 28 March 2008, Luck, Tony wrote: > > So it makes little sense to add this to semaphores. =A0Better to in= troduce > > a spinaphore, as you say. >=20 > > struct { > > =A0 atomic_t cur; > > =A0 int max; > > } ss_t; >=20 > Could this API sneak into the bottom of one or the other of > linux/include/{spinlock,semaphore}.h ... or should it get its own > spinaphore.h file? > > Or should I follow Alan's earlier advice and keep this as an ia64 > only thing (since I'll be the only user). If you use the simple version suggested last by Willy, I think it could even be open-coded in your TLB management code. Should we decided to make it an official interface, I'd suggest putting it into atomic.h, because it operates on a plain atomic_t. Arnd <>< From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de ([212.227.126.183]:55572 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756330AbYC1Xsn convert rfc822-to-8bit (ORCPT ); Fri, 28 Mar 2008 19:48:43 -0400 From: Arnd Bergmann Subject: Re: down_spin() implementation Date: Sat, 29 Mar 2008 00:48:21 +0100 References: <1FE6DD409037234FAB833C420AA843ECE9DF60@orsmsx424.amr.corp.intel.com> <20080328124517.GQ16721@parisc-linux.org> <1FE6DD409037234FAB833C420AA843ECF237C0@orsmsx424.amr.corp.intel.com> In-Reply-To: <1FE6DD409037234FAB833C420AA843ECF237C0@orsmsx424.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-ID: <200803290048.22931.arnd@arndb.de> Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Luck, Tony" Cc: Matthew Wilcox , Nick Piggin , Stephen Rothwell , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Message-ID: <20080328234821.cbXeIaSm320IxFP7AHo-jUawY5qYHxjV3cM9SUeiD18@z> On Friday 28 March 2008, Luck, Tony wrote: > > So it makes little sense to add this to semaphores.  Better to introduce > > a spinaphore, as you say. > > > struct { > >   atomic_t cur; > >   int max; > > } ss_t; > > Could this API sneak into the bottom of one or the other of > linux/include/{spinlock,semaphore}.h ... or should it get its own > spinaphore.h file? > > Or should I follow Alan's earlier advice and keep this as an ia64 > only thing (since I'll be the only user). If you use the simple version suggested last by Willy, I think it could even be open-coded in your TLB management code. Should we decided to make it an official interface, I'd suggest putting it into atomic.h, because it operates on a plain atomic_t. Arnd <><