Re: question about spinlocks on UP
Andi Kleen (ak@muc.de)
Wed, 15 Jul 1998 18:41:12 +0200
On Wed, Jul 15, 1998 at 06:09:26PM +0200, Savochkin Andrey Vladimirovich wrote:
> On Wed, Jul 15, 1998 at 04:19:33PM +0200, Andi Kleen wrote:
> > Oliver Neukum <neukum@fachschaft.org.chemie.uni-muenchen.de> writes:
> >
> > > is the first parameter of spin_lock_irqsave relevant on UP ?
> > > In other words is
> > >
> > > #ifdef SMP
> > > spinlock_t lock_xxx ...
> > > #endif
> > >
> > > #ifdef SMP
> > > spin_lock_irqsave(&lock_xxx,flags);
> > > #else
> > > spin_lock_irqsave(NULL,flags);
> > > #endif
> > >
> > > without side effects and is that worth it ?
> > > I don't like declaring a global variable unnecessary.
> >
> > spinlocks are generally a nop on UP. Because they're macros you can
> > just write
> >
> >
> > #ifdef SMP
> > spinlock_t bla_lock;
> > #endif
> >
> > ....
> >
> > spin_lock_irqsave(&bla_lock, flags);
> >
> > The preprocessor will remove the &bla_lock in the UP case.
>
> I would not recommend the technique for the common use.
> The similar code was a pain for me when I debugged deadlocks
> and turned on spinlock emulation on UP kernel :-)
>
> I don't think that a certain number of spinlock_t variables are
> worth the time needed to fix all missing declarations when
> you decide to debug something.
The problem are static spinlock variables. If you don't reference them,
and don't #ifdef them out then gcc will always spew out an ugly warning.
It seems to be the Linux kernel consensus that all code should compile
warning free, and just making all spinlocks global would be a serious
namespace pollution and a mainteance nightmare on the long run.
The concept of a spinlock is meaningless on UP anyways, so I don't
think you should do that. Spinlocks have to be NOPs on UP.
You could always use a SMP compiled kernel on a UP machine, but of course
such spinlock "testing" would be fairly useless, because the spinlocks are
never exercised.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html