qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] linux-user crashing in multi-threaded programs


From: Alexander Graf
Subject: Re: [Qemu-devel] linux-user crashing in multi-threaded programs
Date: Mon, 21 Nov 2011 10:55:50 +0100

On 21.11.2011, at 09:54, Peter Maydell wrote:

> On 21 November 2011 02:05, Alexander Graf <address@hidden> wrote:
>> In an adventure to find out why yast2-core fails in its testsuite during 
>> build on ARM for us, I dove into the code for a bit and debugged it down to 
>> our old friend: multi-threaded TB invalidation.
> 
> https://bugs.launchpad.net/qemu/+bug/668799

Yeah, I keep running into the s/interrupt_lock/tb_lock/ patch which fails to 
solve the issue for me.

> 
>> I have a nice test case at
>> 
>>  http://csgraf.de/tmp/yast2-core.tbz2
>> 
>> which you can easily use to reproduce the race.
> 
> There's also a test case attached to 668799.

Oops :). Oh well - the more the merrier :).

> 
>> Does anyone have pending patches, approaches or ideas on how to
>> fix this? It seems to be the last big road block towards getting
>> linux-user actually workable for us.
> 
> I think I sent you my work-in-progress patch, didn't I?

I know that we talked about it. But I can't find it. That doesn't mean that you 
didn't send it, but either way I'd really like to see your patch somewhere 
where it can be found by more people than just me. How about the bug report? :)

> The basic idea is that we throw away this code which tries
> to unlink TB chains, and instead we just have a simple flag
> which we check at the start of each TB (cost: a few insns
> and a load from something that will be in L1), and a
> thread wanting to cause a cpu exit simply sets the flag.
> 
> There are a couple of things in the patch that needed cleaning
> up but the main reason I didn't get round to doing anything with
> it was that I wanted to benchmark it for speed and I don't
> have a nice benchmarking setup... (my very rough tests
> suggested ~3% slowdown which personally I think is an
> acceptable tradeoff for reliability.)

I agree that it's an acceptable tradeoff. There's also always the chance of 
doing tricks like I did in my patch tonight, so you could do the unlinking code 
in single-threaded applications and switch to the more expensive flag check in 
multi-threaded ones.


Alex




reply via email to

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