Il 19/08/2013 15:40, Jan Kiszka ha scritto:
> On 2013-08-19 15:21, Paolo Bonzini wrote:
>> Il 13/08/2013 16:54, Jan Kiszka ha scritto:
> Using an AioContext lock for timers is somewhat complicated for lock
> ordering, because context A could try to modify a timer from context B,
> at th
On 19 Aug 2013, at 14:21, Paolo Bonzini wrote:
> I like Stefan's patches to make the timer list thread-safe, especially
> if we can optimize it (with RCU?) to make the read side lockless.
We will have to be careful on the write side. I'm trying to
work out just how slow this would with Paolo's R
On 2013-08-19 15:21, Paolo Bonzini wrote:
> Il 13/08/2013 16:54, Jan Kiszka ha scritto:
Using an AioContext lock for timers is somewhat complicated for lock
ordering, because context A could try to modify a timer from context B,
at the same time when context B is modifying a timer fr
Il 13/08/2013 16:54, Jan Kiszka ha scritto:
>> > Using an AioContext lock for timers is somewhat complicated for lock
>> > ordering, because context A could try to modify a timer from context B,
>> > at the same time when context B is modifying a timer from context A.
>> > This would cause a deadlo
Il 14/08/2013 14:32, Jan Kiszka ha scritto:
> I still need to check more corner cases as timer dequeuing can now race
> with the handler execution, ie. a dequeued timer can still see one more
> handler run after timer_del returned. That's a property one can easily
> take into account when writing d
On 2013-08-13 16:13, Jan Kiszka wrote:
> On 2013-08-13 15:45, Stefan Hajnoczi wrote:
>> This should make timers usable in another thread for clock device
>> emulation if only your iothread uses the AioContext and its timers
>> (besides the thread-safe mod/del interfaces).
>
> As argued in the othe
On Wed, Aug 14, 2013 at 11:05:29AM +0200, Jan Kiszka wrote:
> On 2013-08-14 10:52, Stefan Hajnoczi wrote:
> > On Tue, Aug 13, 2013 at 04:13:03PM +0200, Jan Kiszka wrote:
> >> On 2013-08-13 15:45, Stefan Hajnoczi wrote:
> >>> On Tue, Aug 13, 2013 at 09:56:17AM +0200, Jan Kiszka wrote:
> >>> The deta
On 2013-08-14 10:52, Stefan Hajnoczi wrote:
> On Tue, Aug 13, 2013 at 04:13:03PM +0200, Jan Kiszka wrote:
>> On 2013-08-13 15:45, Stefan Hajnoczi wrote:
>>> On Tue, Aug 13, 2013 at 09:56:17AM +0200, Jan Kiszka wrote:
>>> The details depend on your device, do you have a git repo I can look at
>>> to
On Tue, Aug 13, 2013 at 04:13:03PM +0200, Jan Kiszka wrote:
> On 2013-08-13 15:45, Stefan Hajnoczi wrote:
> > On Tue, Aug 13, 2013 at 09:56:17AM +0200, Jan Kiszka wrote:
> > The details depend on your device, do you have a git repo I can look at
> > to understand your device model?
>
> Pushed my h
On Tue, Aug 13, 2013 at 10:13 PM, Jan Kiszka wrote:
> On 2013-08-13 15:45, Stefan Hajnoczi wrote:
>> On Tue, Aug 13, 2013 at 09:56:17AM +0200, Jan Kiszka wrote:
>>> in the attempt to use Alex' ppoll-based timer rework for decoupled,
>>> real-time capable timer device models I'm now scratching my h
On 2013-08-13 16:45, Paolo Bonzini wrote:
> Il 13/08/2013 09:56, Jan Kiszka ha scritto:
>> Hi Stefan,
>>
>> in the attempt to use Alex' ppoll-based timer rework for decoupled,
>> real-time capable timer device models I'm now scratching my head over
>> the aio_poll interface. I'm looking at dataplan
Il 13/08/2013 09:56, Jan Kiszka ha scritto:
> Hi Stefan,
>
> in the attempt to use Alex' ppoll-based timer rework for decoupled,
> real-time capable timer device models I'm now scratching my head over
> the aio_poll interface. I'm looking at dataplane/virtio-blk.c, just finding
>
> static void *d
On 2013-08-13 15:45, Stefan Hajnoczi wrote:
> On Tue, Aug 13, 2013 at 09:56:17AM +0200, Jan Kiszka wrote:
>> in the attempt to use Alex' ppoll-based timer rework for decoupled,
>> real-time capable timer device models I'm now scratching my head over
>> the aio_poll interface. I'm looking at datapla
On Tue, Aug 13, 2013 at 09:56:17AM +0200, Jan Kiszka wrote:
> in the attempt to use Alex' ppoll-based timer rework for decoupled,
> real-time capable timer device models I'm now scratching my head over
> the aio_poll interface. I'm looking at dataplane/virtio-blk.c, just finding
>
> static void *d
Hi Stefan,
in the attempt to use Alex' ppoll-based timer rework for decoupled,
real-time capable timer device models I'm now scratching my head over
the aio_poll interface. I'm looking at dataplane/virtio-blk.c, just finding
static void *data_plane_thread(void *opaque)
{
VirtIOBlockDataPlane
15 matches
Mail list logo
