Re: [PATCH] New operation for kref to help avoid locks

[Corey Minyard]

Nick Piggin wrote:

> Corey Minyard wrote:
>
> > Arjan van de Ven wrote:
> >
> > > > Just doing an atomic operation is not faster than doing a lock, an 
> > > > atomic operation, then an unlock?  Am I missing something?
> > > >   
> > >
> > >
> > >
> > > if the lock and the atomic are on the same cacheline they're the same
> > > cost on most modern cpus...
> > >  
> > Ah, I see.  Not likely to ever be the case with this.  The lock will 
> > likely be with the main data structure (the list, or whatever) and 
> > the refcount will be in the individual item in the main data 
> > structure (list entry).
>
> Is get_with_check actually going to be useful for anything? It
> seems like it promotes complex and potentially unsafe schemes.

It is certainly more complex to use this, and I'm guessing that's why 
Greg rejected it.  Certainly a valid problem.

> eg. In your queue example, it would usually be better to have
> a refcount for being on queue, and entry_completed would remove
> the entry from the queue and accordingly drop the refcount. The
> release function would then just free it.

True.  But if things picked up entries of the queue and incremented 
their refcount, then you would need a lock.  The same technique would 
apply.  But your example would be the more common one, I would think.

Thanks,

-Corey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/