From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO30w-0006jI-CI for qemu-devel@nongnu.org; Fri, 15 Jul 2016 09:18:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO30s-0007C5-8m for qemu-devel@nongnu.org; Fri, 15 Jul 2016 09:18:46 -0400 Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:33985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO30s-0007By-0n for qemu-devel@nongnu.org; Fri, 15 Jul 2016 09:18:42 -0400 Received: by mail-lf0-x22e.google.com with SMTP id l69so31348440lfg.1 for ; Fri, 15 Jul 2016 06:18:41 -0700 (PDT) References: <1468354426-837-1-git-send-email-sergey.fedorov@linaro.org> <1468354426-837-2-git-send-email-sergey.fedorov@linaro.org> <1bfb56fa-55dd-455a-e4ec-c34ec7996baa@redhat.com> <5788D8FE.90607@gmail.com> From: Sergey Fedorov Message-ID: <5788E2AF.5050003@gmail.com> Date: Fri, 15 Jul 2016 16:18:39 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 01/11] util/qht: Document memory ordering assumptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Sergey Fedorov , qemu-devel@nongnu.org, mttcg@greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, cota@braap.org, bobby.prani@gmail.com, rth@twiddle.net Cc: peter.maydell@linaro.org, patches@linaro.org, claudio.fontana@huawei.com, mark.burton@greensocs.com, jan.kiszka@siemens.com, =?UTF-8?Q?Alex_Benn=c3=a9e?= On 15/07/16 15:51, Paolo Bonzini wrote: > > On 15/07/2016 14:37, Sergey Fedorov wrote: >> I understand why an implied wmb can be expected after the entry is >> removed: so that the caller can trash the contents of the object >> removed. However that would require double-check on lookup side to make >> sure the entry hadn't been removed after the first lookup (something >> like seqlock read side). But I have no idea why we might like to promise >> wmb before the removal. Could you please share your point regarding this? > The reasoning was to make qht_remove() "look to be ordered" with respect > to writes. So anything after remove wouldn't bleed into it, nor would > anything before. > > In the case of this series, it would let you remove the smp_wmb() after > tb_mark_invalid(). However, it's also okay to only handle qht_insert() > and qht_lookup(), and keep the memory barrier after the TB is marked > invalid (though it is unnecessary). > I'm pretty sure the smp_wmb() after tb_mark_invalid() is unnecessary anyway. We don't rely on it at all because we're to recheck for tb_is_invalid() under tb_lock before tb_add_jump(). However we have to invalidate the CPU state atomically since we're going to check for it out of tb_lock. Kind regards, Sergey