From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bml8b-0003Fb-G9 for qemu-devel@nongnu.org; Wed, 21 Sep 2016 13:16:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bml8W-0001MC-GY for qemu-devel@nongnu.org; Wed, 21 Sep 2016 13:16:49 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:37243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bml8W-0001M5-AQ for qemu-devel@nongnu.org; Wed, 21 Sep 2016 13:16:44 -0400 Received: by mail-wm0-f47.google.com with SMTP id b130so103083859wmc.0 for ; Wed, 21 Sep 2016 10:16:44 -0700 (PDT) Sender: Paolo Bonzini References: <1474289459-15242-1-git-send-email-pbonzini@redhat.com> <1474289459-15242-8-git-send-email-pbonzini@redhat.com> <20160921170334.GE13385@flamenco> From: Paolo Bonzini Message-ID: <2d1b66e0-b0ea-e5f5-b4da-ebeb22fa5217@redhat.com> Date: Wed, 21 Sep 2016 19:15:41 +0200 MIME-Version: 1.0 In-Reply-To: <20160921170334.GE13385@flamenco> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/16] cpus-common: move CPU work item management to common code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Emilio G. Cota" Cc: serge.fdrv@gmail.com, alex.bennee@linaro.org, qemu-devel@nongnu.org, sergey.fedorov@linaro.org On 21/09/2016 19:03, Emilio G. Cota wrote: >> > - wi = g_malloc0(sizeof(struct qemu_work_item)); >> > - wi->func = func; >> > - wi->data = data; >> > - wi->free = true; >> > - >> > - queue_work_on_cpu(cpu, wi); >> > + do_run_on_cpu(cpu, func, data, &qemu_global_mutex); >> > } > AFAICT this is the only caller of do_run_on_cpu. Is qemu_global_mutex > necessary here? I wonder if we could just use cpu->work_mutex to wait > on a per-cpu work_cond. Contending for a global lock here doesn't > make much sense unless I'm missing something. Furthermore, that change > would allow us to get rid of the atomic accesses to wi.done, which I > dislike. Yes, this will be a follow up. We pass qemu_global_mutex here for qemu_cond_wait to drop the BQL. But the real solution is to run work item outside the BQL; they don't need it. Paolo