[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] atomic: using memory_order_relaxed for refcn

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2] atomic: using memory_order_relaxed for refcnt inc/dec ops
Date: Mon, 15 Jul 2013 12:39:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Il 14/07/2013 12:23, liu ping fan ha scritto:
>> if the refcount ops are frequent enough, I strongly suspect cacheline
>> bouncing has a bigger effect than the memory barriers.
> When out of biglock, object_ref/unref to pin the Device will be quite
> often, and can it be marked "frequent"? Or how can we say something is
> frequent?

I didn't say it is not frequent.  I said I suspect (it _is_ just a
suspicion, not the result of a benchmark, but at least I said so...)
that "cacheline bouncing has a bigger effect than the memory barriers"
and thus the API would not have such a dramatic impact.

>> Third, it is making the API completely unorthogonal, and "tend to be
>> exceptions" is not a justification.
>> The justification here could be, rather than the performance, having to
>> remember how to use atomic_fetch_dec in the unref side.  I don't really
>> buy that, but if you really care, do something like
>> #define atomic_ref(ptr, field)
>> #define atomic_unref(ptr, field, releasefn)
>> i.e. define a new interface similar to kref_get/kref_put and, since you
>> are at it, optimize it.
> Thanks, a abstract layer for refct is what I need.

If someone cares enough to review your patch (which _must_ come with
documentation), that's fine for me.  I don't think it's worthwhile, but
others may disagree.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]