Re: kmalloc without GFP_xxx?

Jörn Engel
2005-06-29T15:11:44Z

On Wed, 29 June 2005 10:53:10 -0400, Steven Rostedt wrote:
> On Wed, 29 Jun 2005, Jörn Engel wrote:
> > On Wed, 29 June 2005 17:14:32 +0300, Denis Vlasenko wrote:
> > >
> > > This is why I always use _irqsave. Less error prone.
> > > And locking is a very easy to get 'slightly' wrong, thus
> > > I trade 0.1% of performance for code simplicity.
> >
> > But sometimes you get lucky and trade 100ms latency for code
> > simplicity. Of course, the audio people don't mind anymore, now that
> > we have all sorts of realtime patches. Everyone's happy!
> >
>
> God! If you are holding a spin_lock for 100ms, something is terribly
> wrong, especialy since you better not schedule holding that spin_lock.
> Spinlocks are _suppose_ to be for quick things. The difference in latency
> between a *_lock and *_lock_irqsave only effects UP, on SMP both will give
> the same latency, since another CPU might be busy spinning while waiting
> for that lock, heck, on SMP the latency of *_lock can actually be higher,
> since, as I already said, the other CPU will even have to wait while the
> CPU that has the lock is servicing interrupts.

All nice and well. But still, for the sake of simplicity and me not
wanting to think, I prefer always using spin_lock_irqsave for
everything. Since when should I stop and think about my own code?

In fact, why don't we all sit down and start using KCSP for kernel
hacking? ;)

Jörn

--
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000