From patchwork Fri Jul 24 05:56:16 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wen Congyang X-Patchwork-Id: 499599 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 61598140DBC for ; Fri, 24 Jul 2015 15:56:47 +1000 (AEST) Received: from localhost ([::1]:43719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIVyN-0006Bn-2w for incoming@patchwork.ozlabs.org; Fri, 24 Jul 2015 01:56:43 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIVy9-0005uE-8W for qemu-devel@nongnu.org; Fri, 24 Jul 2015 01:56:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZIVy6-0001oL-1E for qemu-devel@nongnu.org; Fri, 24 Jul 2015 01:56:29 -0400 Received: from [59.151.112.132] (port=26666 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIVy4-0001mN-F6 for qemu-devel@nongnu.org; Fri, 24 Jul 2015 01:56:25 -0400 X-IronPort-AV: E=Sophos;i="5.15,520,1432569600"; d="scan'208";a="98805743" Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 24 Jul 2015 13:59:55 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (localhost.localdomain [127.0.0.1]) by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id t6O5sRha004763; Fri, 24 Jul 2015 13:54:27 +0800 Received: from [10.167.226.52] (10.167.226.52) by G08CNEXCHPEKD02.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server id 14.3.181.6; Fri, 24 Jul 2015 13:56:15 +0800 To: Paolo Bonzini , Wen Congyang , Christian Borntraeger , References: <1437574681-18362-2-git-send-email-pbonzini@redhat.com> <55B0C24C.7020401@de.ibm.com> <55B0C527.8060502@redhat.com> <55B0CA2D.3060506@cn.fujitsu.com> <55B0CB47.2070301@redhat.com> <55B0E522.1000009@gmail.com> <55B11D26.10402@redhat.com> From: Wen Congyang Message-ID: <55B1D380.7020300@cn.fujitsu.com> Date: Fri, 24 Jul 2015 13:56:16 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B11D26.10402@redhat.com> X-Originating-IP: [10.167.226.52] X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 59.151.112.132 Subject: Re: [Qemu-devel] [PATCH] rcu: actually register threads that have RCU read-side critical sections X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On 07/24/2015 12:58 AM, Paolo Bonzini wrote: > > > On 23/07/2015 14:59, Wen Congyang wrote: >>>> >>>> If the thread doesn't use RCU, rcu_register_thread() is harmless, is >>>> it right? >>> >>> Every rcu_register_thread() makes synchronize_rcu() a little slower. >> >> Yes, but synchronize_rcu() is very slow... > > Hmm, worse, rcu_register_thread() if called together with > synchronize_rcu() it waits for the synchronize_rcu() to finish. :/ What about this modification: rcu_register_thread() will be a littl slower when it is called together with synchronize_rcu(). Thanks Wen Congyang > > Paolo > >>> >>>>>> be simpler to add an assertion in rcu_register_thread. I'm just a bit >>>>>> wary of doing little more than the bare minimum in 2.4, because of the >>>>>> OS X failure that I didn't quite understand. >>>> Which problem? I don't find it in the maillist. >>> >>> http://article.gmane.org/gmane.comp.emulators.qemu/351548 >> >> Hmm, I guess rcu_reader is invalid when pthread key is destroyed. >> pthread key and __thread >> variable, which is destroyed first? I don't find any document to >> describe it. > diff --git a/util/rcu.c b/util/rcu.c index 7270151..ccf8cfa 100644 --- a/util/rcu.c +++ b/util/rcu.c @@ -48,6 +48,7 @@ unsigned long rcu_gp_ctr = RCU_GP_LOCKED; QemuEvent rcu_gp_event; static QemuMutex rcu_gp_lock; +static QemuMutex rcu_sync_lock; /* * Check whether a quiescent state was crossed between the beginning of @@ -115,9 +116,12 @@ static void wait_for_readers(void) } /* Wait for one thread to report a quiescent state and - * try again. + * try again. Release rcu_gp_lock, so rcu_(un)register_thread() + * doesn't wait too much time. */ + qemu_mutex_unlock(&rcu_gp_lock); qemu_event_wait(&rcu_gp_event); + qemu_mutex_lock(&rcu_gp_lock); } /* put back the reader list in the registry */ @@ -126,6 +130,7 @@ static void wait_for_readers(void) void synchronize_rcu(void) { + qemu_mutex_lock(&rcu_sync_lock); qemu_mutex_lock(&rcu_gp_lock); if (!QLIST_EMPTY(®istry)) { @@ -150,6 +155,7 @@ void synchronize_rcu(void) } qemu_mutex_unlock(&rcu_gp_lock); + qemu_mutex_unlock(&rcu_sync_lock); } @@ -288,6 +294,7 @@ static void rcu_init_complete(void) QemuThread thread; qemu_mutex_init(&rcu_gp_lock); + qemu_mutex_init(&rcu_sync_lock); qemu_event_init(&rcu_gp_event, true); qemu_event_init(&rcu_call_ready_event, false); @@ -304,12 +311,14 @@ static void rcu_init_complete(void) #ifdef CONFIG_POSIX static void rcu_init_lock(void) { + qemu_mutex_lock(&rcu_sync_lock); qemu_mutex_lock(&rcu_gp_lock); } static void rcu_init_unlock(void) { qemu_mutex_unlock(&rcu_gp_lock); + qemu_mutex_unlock(&rcu_sync_lock); } #endif