From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UygBk-0006yA-QT for qemu-devel@nongnu.org; Mon, 15 Jul 2013 06:39:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UygBj-00067c-TT for qemu-devel@nongnu.org; Mon, 15 Jul 2013 06:39:28 -0400 Received: from mail-ea0-x22a.google.com ([2a00:1450:4013:c01::22a]:35806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UygBj-00067W-N5 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 06:39:27 -0400 Received: by mail-ea0-f170.google.com with SMTP id h10so7848510eaj.1 for ; Mon, 15 Jul 2013 03:39:26 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51E3D155.7040406@redhat.com> Date: Mon, 15 Jul 2013 12:39:17 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373770422-5111-1-git-send-email-pingfank@linux.vnet.ibm.com> <51E23DE2.2040908@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] atomic: using memory_order_relaxed for refcnt inc/dec ops List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: qemu-devel@nongnu.org, Richard Henderson 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. Paolo