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

From: Corey Minyard (minyard_at_acm.org)
Date: 03/01/05

  • Next message: Andrew Morton: "Re: 2.6.11-rc5-mm1" 
    Date:	Tue, 01 Mar 2005 15:54:33 -0600
To: Arjan van de Ven <arjan@infradead.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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Andrew Morton: "Re: 2.6.11-rc5-mm1"

    Relevant Pages

    • Re: + slub-avoid-atomic-operation-for-slab_unlock.patch added to -mm tree
      ... Subject: SLUB: avoid atomic operation for slab_unlock ... Currently page flags are only modified in SLUB under page lock. ...
      (Linux-Kernel)
    • Re: [PATCH] New operation for kref to help avoid locks
      ... >>atomic operation, then an unlock? ... The lock will ... refcount will be in the individual item in the main data structure (list ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Multithreaded GC!
      ... atomic operation. ... Yes, and they will keep calling it that way (in X86), but modern processors do get smarter and no longer require to lock the bus. ... I'm actually less concerned about the current 5x performance hit and more ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: C#, Threads, Events, and DataGrids/DataSets
      ... Native integer assignment is atomic operation as well as native integer ... Using LOCK for accessing it would be unnecessary performance hit if not to ...
      (microsoft.public.dotnet.general)
    • Re: Atomic Add
      ... both require one atomic operation. ... "lock; cmpxchg" which I used in the second method. ... int main{ ...
      (comp.programming.threads)