On 07/24/2015 02:22 PM, Paolo Bonzini wrote:
>
>
> On 24/07/2015 07:56, Wen Congyang wrote:
>> @@ -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
On 24/07/2015 07:56, Wen Congyang wrote:
> @@ -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()
> + * d
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() i
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() i
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 call
At 2015/7/23 19:08, Paolo Bonzini Wrote:
On 23/07/2015 13:04, Wen Congyang wrote:
Yes. I think this is better for 2.4. There are threads that do not
need RCU, for example the thread-pool.c worker threads, so it may just
If the thread doesn't use RCU, rcu_register_thread() is harmless, is i
On 23/07/2015 13:04, Wen Congyang wrote:
> > Yes. I think this is better for 2.4. There are threads that do not
> > need RCU, for example the thread-pool.c worker threads, so it may just
>
> If the thread doesn't use RCU, rcu_register_thread() is harmless, is it right?
Every rcu_register_threa
On 07/23/2015 06:42 PM, Paolo Bonzini wrote:
>
>
> On 23/07/2015 12:30, Christian Borntraeger wrote:
>> Am 22.07.2015 um 16:18 schrieb Paolo Bonzini:
>>> Otherwise, grace periods are detected too early!
>>
>> I guess this or Wens proposal is still necessary for 2.4?
>
> Yes. I think this is bet
On 23/07/2015 12:30, Christian Borntraeger wrote:
> Am 22.07.2015 um 16:18 schrieb Paolo Bonzini:
>> Otherwise, grace periods are detected too early!
>
> I guess this or Wens proposal is still necessary for 2.4?
Yes. I think this is better for 2.4. There are threads that do not
need RCU, for
Am 22.07.2015 um 16:18 schrieb Paolo Bonzini:
> Otherwise, grace periods are detected too early!
I guess this or Wens proposal is still necessary for 2.4?
>
> Signed-off-by: Paolo Bonzini
> ---
> cpus.c| 6 ++
> iothread.c| 5 +
> migration/migration.c | 4
On 23/07/2015 04:56, Wen Congyang wrote:
>> > Otherwise, grace periods are detected too early!
> We always use qemu_thread_create() in qemu. So I think we can do it like this:
> wrapped_fn()
> {
> rcu_register_thread();
> call thread_fn() here
> rcu_unregister_thread();
> }
>
> So we
On 07/22/2015 10:18 PM, Paolo Bonzini wrote:
> Otherwise, grace periods are detected too early!
We always use qemu_thread_create() in qemu. So I think we can do it like this:
wrapped_fn()
{
rcu_register_thread();
call thread_fn() here
rcu_unregister_thread();
}
So we will never forget
Otherwise, grace periods are detected too early!
Signed-off-by: Paolo Bonzini
---
cpus.c| 6 ++
iothread.c| 5 +
migration/migration.c | 4
tests/test-rcu-list.c | 4
util/rcu.c| 2 ++
5 files changed, 21 insertions(+)
diff --git a/cpus.
13 matches
Mail list logo
