From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58015)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1b5dJa-0001HQ-Bc
	for qemu-devel@nongnu.org; Wed, 25 May 2016 14:13:55 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1b5dJW-0005Hh-1X
	for qemu-devel@nongnu.org; Wed, 25 May 2016 14:13:53 -0400
Received: from mail-lf0-x243.google.com ([2a00:1450:4010:c07::243]:36025)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1b5dJV-0005Gy-3G
	for qemu-devel@nongnu.org; Wed, 25 May 2016 14:13:49 -0400
Received: by mail-lf0-x243.google.com with SMTP id d132so3931176lfb.3
	for <qemu-devel@nongnu.org>; Wed, 25 May 2016 11:13:49 -0700 (PDT)
References: <1459870344-16773-1-git-send-email-alex.bennee@linaro.org>
	<1459870344-16773-4-git-send-email-alex.bennee@linaro.org>
	<570C0276.8040501@gmail.com> <5745C940.4040306@gmail.com>
	<1739678314.17238390.1464199420968.JavaMail.zimbra@redhat.com>
From: Sergey Fedorov <serge.fdrv@gmail.com>
Message-ID: <5745EB5A.5080901@gmail.com>
Date: Wed, 25 May 2016 21:13:46 +0300
MIME-Version: 1.0
In-Reply-To: <1739678314.17238390.1464199420968.JavaMail.zimbra@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC v2 03/11] docs: new design document
 multi-thread-tcg.txt (DRAFTING)
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>, mttcg@greensocs.com, fred konrad <fred.konrad@greensocs.com>, a rigo <a.rigo@virtualopensystems.com>, cota@braap.org, qemu-devel@nongnu.org, mark burton <mark.burton@greensocs.com>, jan kiszka <jan.kiszka@siemens.com>, rth@twiddle.net, peter maydell <peter.maydell@linaro.org>, claudio fontana <claudio.fontana@huawei.com>

On 25/05/16 21:03, Paolo Bonzini wrote:
>> The page table seems to be protected by 'mmap_lock' in user mode
>> emulation but by 'tb_lock' in system mode emulation. It may turn to be
>> possible to read it safely even with no lock held.
> Yes, it is possible to at least follow the radix tree safely with no
> lock held.  The fields in the leaves can be either lockless or protected
> by a lock.
>
> The radix tree can be followed without a lock just like you do with RCU.
> The difference with RCU is that:
>
> 1) the leaves are protected with a lock, so you don't do the "copy";
> instead after reading you lock around updates
>
> 2) the radix tree is only ever added to, so you don't need to protect
> the reads with rcu_read_lock/rcu_read_unlock.  rcu_read_lock and
> rcu_read_unlock are only needed to inform the deleters that something
> cannot yet go away.  Without deleters, you don't need rcu_read_lock
> and rcu_read_unlock (but you still need atomic_rcu_read/atomic_rcu_set).
>
>

Yes, however looking closer at how the leafs are used I can't see much
point to do this so far...

Thanks,
Sergey