On 10/07/2015 12:24, Paolo Bonzini wrote:
On 10/07/2015 11:47, alvise rigo wrote:
I tried to use it, but it would then create a deadlock at a very early
stage of the stress test.
The problem is likely related to the fact that flush_queued_work
happens with the global mutex locked.
Let's fix th
On 10/07/2015 11:47, alvise rigo wrote:
> I tried to use it, but it would then create a deadlock at a very early
> stage of the stress test.
> The problem is likely related to the fact that flush_queued_work
> happens with the global mutex locked.
Let's fix that and move the global mutex inside
On Fri, Jul 10, 2015 at 11:53 AM, Frederic Konrad
wrote:
> On 10/07/2015 11:47, alvise rigo wrote:
>>
>> I tried to use it, but it would then create a deadlock at a very early
>> stage of the stress test.
>> The problem is likely related to the fact that flush_queued_work
>> happens with the globa
On 10/07/2015 11:47, alvise rigo wrote:
I tried to use it, but it would then create a deadlock at a very early
stage of the stress test.
The problem is likely related to the fact that flush_queued_work
happens with the global mutex locked.
As Frederick suggested, we can use the newly introduced
I tried to use it, but it would then create a deadlock at a very early
stage of the stress test.
The problem is likely related to the fact that flush_queued_work
happens with the global mutex locked.
As Frederick suggested, we can use the newly introduced
flush_queued_safe_work for this.
Regards,
On 10/07/2015 10:23, Alvise Rigo wrote:
> In order to perfom "lazy" TLB invalidation requests, introduce a
> queue of callbacks at every vCPU disposal that will be fired just
> before entering the next TB.
>
> Suggested-by: Jani Kokkonen
> Suggested-by: Claudio Fontana
> Signed-off-by: Alvise
In order to perfom "lazy" TLB invalidation requests, introduce a
queue of callbacks at every vCPU disposal that will be fired just
before entering the next TB.
Suggested-by: Jani Kokkonen
Suggested-by: Claudio Fontana
Signed-off-by: Alvise Rigo
---
cpus.c| 34 ++
