On Tue, Mar 08, 2016 at 10:58:47AM +0100, Kevin Wolf wrote:
> Am 07.03.2016 um 21:56 hat Stefan Hajnoczi geschrieben:
> > On Mon, Mar 07, 2016 at 05:57:41PM +0100, Kevin Wolf wrote:
> > > Am 23.02.2016 um 14:54 hat Paolo Bonzini geschrieben:
> > > >
> > > >
> > > > On 23/02/2016 13:49, Fam Zheng
On Mon, Mar 07, 2016 at 10:22:58PM +0100, Paolo Bonzini wrote:
> On 07/03/2016 21:56, Stefan Hajnoczi wrote:
> > I think the timer concept itself is troublesome. A radical approach but
> > limited to changing QED itself is to drop the timer and instead keep a
> > timestamp for the last allocating
On 07/03/2016 21:56, Stefan Hajnoczi wrote:
> I think the timer concept itself is troublesome. A radical approach but
> limited to changing QED itself is to drop the timer and instead keep a
> timestamp for the last allocating write request. Next time a write
> request (allocating or
By the way, I'll send a patch on Tuesday showing the timerless need
check mechanism. It's a little too late tonight to start it.
Stefan
signature.asc
Description: PGP signature
On Mon, Mar 07, 2016 at 05:57:41PM +0100, Kevin Wolf wrote:
> Am 23.02.2016 um 14:54 hat Paolo Bonzini geschrieben:
> >
> >
> > On 23/02/2016 13:49, Fam Zheng wrote:
> > > On Tue, 02/23 11:43, Paolo Bonzini wrote:
> > >>
> > >>
> > >> On 23/02/2016 06:57, Fam Zheng wrote:
> > >> +
Am 23.02.2016 um 14:54 hat Paolo Bonzini geschrieben:
>
>
> On 23/02/2016 13:49, Fam Zheng wrote:
> > On Tue, 02/23 11:43, Paolo Bonzini wrote:
> >>
> >>
> >> On 23/02/2016 06:57, Fam Zheng wrote:
> >> +qed_cancel_need_check_timer(s);
> >> +qed_need_check_timer_cb(s);
>
On Tue, 02/23 11:43, Paolo Bonzini wrote:
>
>
> On 23/02/2016 06:57, Fam Zheng wrote:
> +qed_cancel_need_check_timer(s);
> +qed_need_check_timer_cb(s);
> +}
> >>>
> >>> What if an allocating write is queued (the else branch case)? Its
> >>> completion
> >>>
On 23/02/2016 06:57, Fam Zheng wrote:
+qed_cancel_need_check_timer(s);
+qed_need_check_timer_cb(s);
+}
>>>
>>> What if an allocating write is queued (the else branch case)? Its completion
>>> will be in bdrv_drain and it could arm the need_check_timer which is
On Wed, 02/17 12:28, Paolo Bonzini wrote:
>
>
> On 17/02/2016 03:57, Fam Zheng wrote:
> > On Tue, 02/16 16:53, Paolo Bonzini wrote:
> >> The current implementation of bdrv_qed_drain can cause a double
> >> completion of a request.
> >>
> >> The problem is that bdrv_qed_drain calls
On 17/02/2016 03:57, Fam Zheng wrote:
> On Tue, 02/16 16:53, Paolo Bonzini wrote:
>> The current implementation of bdrv_qed_drain can cause a double
>> completion of a request.
>>
>> The problem is that bdrv_qed_drain calls qed_plug_allocating_write_reqs
>> unconditionally, but this is not
On Tue, 02/16 16:53, Paolo Bonzini wrote:
> The current implementation of bdrv_qed_drain can cause a double
> completion of a request.
>
> The problem is that bdrv_qed_drain calls qed_plug_allocating_write_reqs
> unconditionally, but this is not correct if an allocating write
> is queued. In
The current implementation of bdrv_qed_drain can cause a double
completion of a request.
The problem is that bdrv_qed_drain calls qed_plug_allocating_write_reqs
unconditionally, but this is not correct if an allocating write
is queued. In this case, qed_unplug_allocating_write_reqs will
restart
12 matches
Mail list logo
