qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/3] tcg: Avoid bouncing tb_lock between tb_gen_


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 3/3] tcg: Avoid bouncing tb_lock between tb_gen_code() and tb_add_jump()
Date: Fri, 8 Jul 2016 07:02:30 -0400 (EDT)

> On 08/07/16 11:40, Paolo Bonzini wrote:
> > Even better: add a "bool *tb_locked" argument to tb_find_slow, and
> > don't move the mmap_lock release.  Then tb_find_fast knows directly
> > whether tb_lock is taken, and you don't need any of tb_lock_reset
> > or mmap_lock_reset.
> 
> I think we can do even better. One option is using a separate tiny lock
> to protect direct jump set/reset instead of tb_lock.

If you have to use a separate tiny lock, you don't gain anything compared
to the two critical sections, do you?

In any case, this seems to be more complex than necessary.  The "bool *"
convention is pretty common in Linux for example---it works well.

The one below is even more complicated.  I'm all for simple lock-free
stacks (e.g. QSLIST_INSERT_HEAD_ATOMIC and QSLIST_MOVE_ATOMIC), but lock-free
lists are too much, especially if with the complicated first/next mechanism
of TCG's chained block lists.

Paolo

> Another option which I've had in my mind for some time is to make direct
> jump set/reset thread-safe. We already have thread-safe TB patching. The
> only question is the right order of operations and handling
> jmp_list_next/jmp_list_first safely. I think that could be done by
> removing tb_remove_from_jmp_list() and making RCU-like manipulation with
> jmp_list_next/jmp_list_first. What do you think?
> 
> Kind regards,
> Sergey
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]