All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Greg KH <greg@kroah.com>, Sergey Vlasov <vsu@altlinux.ru>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] New operation for kref to help avoid locks
Date: Tue, 01 Mar 2005 15:54:33 -0600	[thread overview]
Message-ID: <4224E499.5060800@acm.org> (raw)
In-Reply-To: <1109710964.6293.166.camel@laptopd505.fenrus.org>

Arjan van de Ven wrote:

>On Tue, 2005-03-01 at 12:15 -0800, Greg KH wrote:
>  
>
>>On Sat, Feb 26, 2005 at 04:23:04PM -0600, Corey Minyard wrote:
>>    
>>
>>>Add a routine to kref that allows the kref_put() routine to be
>>>unserialized even when the get routine attempts to kref_get()
>>>an object without first holding a valid reference to it.  This is
>>>useful in situations where this happens multiple times without
>>>freeing the object, as it will avoid having to do a lock/semaphore
>>>except on the final kref_put().
>>>
>>>This also adds some kref documentation to the Documentation
>>>directory.
>>>      
>>>
>>I like the first part of the documentation, that's nice.
>>
>>But I don't like the new kref_get_with_check() function that you
>>implemented.  If you look in the -mm tree, kref_put() now returns if
>>this was the last put on the reference count or not, to help with lists
>>of objects with a kref in it.
>>
>>Perhaps you can use that to implement what you need instead?
>>    
>>
Yes, that helps a lot.  I had actually already implemented something 
like that :).  But that's a different thing than avoiding the lock.

It's just that with the I2C stuff, you may be calling kref_put() 20-30 
times for a single operation.  That's a lot of lock/unlock operations.  
But it is wierd, so I understand.  Thanks.

>
>note that I'm not convinced the "lockless" implementation actually is
>faster. It still uses an atomic variable, which is just as expensive as
>taking a lock normally...
>  
>
Just doing an atomic operation is not faster than doing a lock, an 
atomic operation, then an unlock?  Am I missing something?

-Corey

  parent reply	other threads:[~2005-03-01 21:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-26 15:55 [PATCH] New operation for kref to help avoid locks Corey Minyard
2005-02-26 20:20 ` Sergey Vlasov
2005-02-26 22:23   ` Corey Minyard
2005-03-01 20:15     ` Greg KH
2005-03-01 21:02       ` Arjan van de Ven
2005-03-01 21:24         ` Greg KH
2005-03-01 21:54         ` Corey Minyard [this message]
2005-03-01 22:14           ` Arjan van de Ven
2005-03-01 23:35             ` Corey Minyard
2005-03-02  0:02               ` Nick Piggin
2005-03-02  0:28                 ` Corey Minyard
2005-03-02  0:34                   ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4224E499.5060800@acm.org \
    --to=minyard@acm.org \
    --cc=arjan@infradead.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vsu@altlinux.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.