On Fri, Sep 08, 2017 at 01:49:41PM +0200, Markus Armbruster wrote:
> > I also see the other problem as keeping the management level
> > understanding of which commands are asynchronous; Dan's suggestion is
> > that command where the management layer specifies which commands it
> > expects to be asy
On Mon, Sep 11, 2017 at 06:32:03PM +0800, Peter Xu wrote:
[...]
> I think this OOB solution should work for us, though I'm still trying
> to digest this whole thing. Thanks Markus for this design, much
> appreciated. Meanwhile, sorry to have troubled you on this. I really
> didn't mean to!
>
>
On Fri, Sep 08, 2017 at 01:49:41PM +0200, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" writes:
> >>
> >> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> >> "Daniel P. Berrange" writes:
> >>
On Fri, Sep 8, 2017 at 12:49 PM, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" writes:
>
>> * Markus Armbruster (arm...@redhat.com) wrote:
>>> "Dr. David Alan Gilbert" writes:
>>>
>>> > * Markus Armbruster (arm...@redhat.com) wrote:
>>> >> "Daniel P. Berrange" writes:
>>> >>
>>> >> > On T
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" writes:
>>
>> > * Markus Armbruster (arm...@redhat.com) wrote:
>> >> "Daniel P. Berrange" writes:
>> >>
>> >> > On Thu, Sep 07, 2017 at 02:59:28PM +0200, Markus Armbruster wrote:
>> >
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Daniel P. Berrange" writes:
> >>
> >> > On Thu, Sep 07, 2017 at 02:59:28PM +0200, Markus Armbruster wrote:
> >> >> So, what exactly is going to drain the
On Thu, Sep 07, 2017 at 07:41:29PM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > On Thu, Sep 07, 2017 at 02:59:28PM +0200, Markus Armbruster wrote:
> >> So, what exactly is going to drain the command queue? If there's more
> >> than one consumer, how exactly are commands f
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Daniel P. Berrange" writes:
>>
>> > On Thu, Sep 07, 2017 at 02:59:28PM +0200, Markus Armbruster wrote:
>> >> So, what exactly is going to drain the command queue? If there's more
>> >> than one consumer, how
* Markus Armbruster (arm...@redhat.com) wrote:
> "Daniel P. Berrange" writes:
>
> > On Thu, Sep 07, 2017 at 02:59:28PM +0200, Markus Armbruster wrote:
> >> So, what exactly is going to drain the command queue? If there's more
> >> than one consumer, how exactly are commands from the queue dispat
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> Peter Xu writes:
> >>
> >> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> >> >> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. Davi
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> Peter Xu writes:
>>
>> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
>> >> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
>> >> > * Daniel P. Berrange (berra...@
"Daniel P. Berrange" writes:
> On Thu, Sep 07, 2017 at 02:59:28PM +0200, Markus Armbruster wrote:
>> So, what exactly is going to drain the command queue? If there's more
>> than one consumer, how exactly are commands from the queue dispatched to
>> the consumers?
>
> In terms of my proposal, fo
On Thu, Sep 7, 2017 at 6:14 PM, Dr. David Alan Gilbert
wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>> On Thu, Sep 7, 2017 at 1:02 PM, Peter Xu wrote:
>> > On Thu, Sep 07, 2017 at 11:09:29AM +0100, Stefan Hajnoczi wrote:
>> >> On Thu, Sep 7, 2017 at 10:35 AM, Dr. David Alan Gilbert
>> >
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Thu, Sep 7, 2017 at 1:02 PM, Peter Xu wrote:
> > On Thu, Sep 07, 2017 at 11:09:29AM +0100, Stefan Hajnoczi wrote:
> >> On Thu, Sep 7, 2017 at 10:35 AM, Dr. David Alan Gilbert
> >> wrote:
> >> > * Stefan Hajnoczi (stefa...@gmail.com) wrote:
> >> >
On Thu, Sep 7, 2017 at 1:02 PM, Peter Xu wrote:
> On Thu, Sep 07, 2017 at 11:09:29AM +0100, Stefan Hajnoczi wrote:
>> On Thu, Sep 7, 2017 at 10:35 AM, Dr. David Alan Gilbert
>> wrote:
>> > * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>> >> On Wed, Sep 6, 2017 at 4:14 PM, Dr. David Alan Gilbert
>
* Markus Armbruster (arm...@redhat.com) wrote:
> Peter Xu writes:
>
> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> >> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> >> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> >> > > This does impl
On 09/06/2017 06:31 AM, Dr. David Alan Gilbert wrote:
>> This does imply that you need a separate monitor I/O processing, from the
>> command execution thread, but I see no need for all commands to suddenly
>> become async. Just allowing interleaved replies is sufficient from the
>> POV of the pro
On Thu, Sep 07, 2017 at 02:59:28PM +0200, Markus Armbruster wrote:
> So, what exactly is going to drain the command queue? If there's more
> than one consumer, how exactly are commands from the queue dispatched to
> the consumers?
In terms of my proposal, for any single command there should only
Peter Xu writes:
> On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
>> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
>> > * Daniel P. Berrange (berra...@redhat.com) wrote:
>> > > This does imply that you need a separate monitor I/O processing, from the
On Thu, Sep 07, 2017 at 11:09:29AM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 7, 2017 at 10:35 AM, Dr. David Alan Gilbert
> wrote:
> > * Stefan Hajnoczi (stefa...@gmail.com) wrote:
> >> On Wed, Sep 6, 2017 at 4:14 PM, Dr. David Alan Gilbert
> >> wrote:
> >> > * Stefan Hajnoczi (stefa...@gmail.co
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> >> On Thu, Sep 07, 2017 at 04:13:41PM +0800, Peter Xu wrote:
> >> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> >> > > On Wed, Sep
"Dr. David Alan Gilbert" writes:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>> On Thu, Sep 07, 2017 at 04:13:41PM +0800, Peter Xu wrote:
>> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
>> > > On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
On Thu, Sep 07, 2017 at 10:18:16AM +0100, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
> > On Thu, Sep 7, 2017 at 9:13 AM, Peter Xu wrote:
> > > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> > >> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr.
On Thu, Sep 7, 2017 at 10:18 AM, Dr. David Alan Gilbert
wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>> On Thu, Sep 7, 2017 at 9:13 AM, Peter Xu wrote:
>> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
>> >> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan
On Thu, Sep 7, 2017 at 10:35 AM, Dr. David Alan Gilbert
wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>> On Wed, Sep 6, 2017 at 4:14 PM, Dr. David Alan Gilbert
>> wrote:
>> > * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>> >> On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
>>
On Thu, Sep 07, 2017 at 11:04:02AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > This does imply that you need a sep
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > This does imply that you need a separate monitor I/O processing, from the
> > > command execution thread, but I see
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Wed, Sep 6, 2017 at 4:14 PM, Dr. David Alan Gilbert
> wrote:
> > * Stefan Hajnoczi (stefa...@gmail.com) wrote:
> >> On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> >> > The root problem is that, monitor commands are all handled in main
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Thu, Sep 07, 2017 at 10:19:47AM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > On Thu, Sep 07, 2017 at 04:13:41PM +0800, Peter Xu wrote:
> > > > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel
On Thu, Sep 07, 2017 at 10:15:09AM +0100, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrange (berra..
On Thu, Sep 07, 2017 at 10:19:47AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Thu, Sep 07, 2017 at 04:13:41PM +0800, Peter Xu wrote:
> > > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> > > > On Wed, Sep 06, 2017 at 12:31:5
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Thu, Sep 07, 2017 at 04:13:41PM +0800, Peter Xu wrote:
> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrange (berra...@
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Thu, Sep 7, 2017 at 9:13 AM, Peter Xu wrote:
> > On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> >> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> >> > * Daniel P. Berrange (berra...@redhat.com) wro
* Peter Xu (pet...@redhat.com) wrote:
> On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> > On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > This does imply that you need a separate monitor I/
On Wed, Sep 6, 2017 at 4:14 PM, Dr. David Alan Gilbert
wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>> On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
>> > The root problem is that, monitor commands are all handled in main
>> > loop thread now, no matter how many monitors we sp
On Thu, Sep 07, 2017 at 04:13:41PM +0800, Peter Xu wrote:
> On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> > On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > This does imply that you need a
On Thu, Sep 7, 2017 at 9:13 AM, Peter Xu wrote:
> On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
>> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
>> > * Daniel P. Berrange (berra...@redhat.com) wrote:
>> > > This does imply that you need a separate mo
On Wed, Sep 06, 2017 at 12:54:28PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > This does imply that you need a separate monitor I/O processing, from the
> > > command execution
On Wed, Sep 06, 2017 at 04:14:37PM +0100, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
> > On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> > > The root problem is that, monitor commands are all handled in main
> > > loop thread now, no matter how many mo
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> > The root problem is that, monitor commands are all handled in main
> > loop thread now, no matter how many monitors we specify. And, if main
> > loop thread hangs due to some reason, all mo
On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> The root problem is that, monitor commands are all handled in main
> loop thread now, no matter how many monitors we specify. And, if main
> loop thread hangs due to some reason, all monitors will be stuck.
I see a larger issue with postc
On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > This does imply that you need a separate monitor I/O processing, from the
> > command execution thread, but I see no need for all commands to suddenly
> > become async. Ju
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Sep 06, 2017 at 11:57:05AM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > On Wed, Sep 06, 2017 at 11:48:51AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrange (berra...@redh
On Wed, Sep 06, 2017 at 11:57:05AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Sep 06, 2017 at 11:48:51AM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > On Wed, Sep 06, 2017 at 10:48:46AM
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Sep 06, 2017 at 11:48:51AM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > On Wed, Sep 06, 2017 at 10:48:46AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrange (berra...@redh
On Wed, Sep 06, 2017 at 11:48:51AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Sep 06, 2017 at 10:48:46AM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > On Wed, Aug 23, 2017 at 02:51:03PM
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Sep 06, 2017 at 10:48:46AM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> > > > v2:
> > > > - fixed "make check" error that patch
On Wed, Sep 06, 2017 at 10:48:46AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> > > v2:
> > > - fixed "make check" error that patchew reported
> > > - moved the thread_join upper in monitor_d
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> > v2:
> > - fixed "make check" error that patchew reported
> > - moved the thread_join upper in monitor_data_destroy(), before
> > resources are released
> > - added one new patch (curr
On Thu, Aug 31, 2017 at 11:31:55AM +0800, Peter Xu wrote:
> Before getting to an conclusion, just want to make sure we have got a
> consensus on that at least we should start to move the monitor command
> handling into a separate thread rather than main thread, am I correct?
Certainly agree on tha
On Wed, Aug 30, 2017 at 11:13:11AM +0100, Daniel P. Berrange wrote:
> On Wed, Aug 30, 2017 at 09:06:20AM +0200, Markus Armbruster wrote:
> > "Daniel P. Berrange" writes:
> >
> > > On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> >
> > >> However, even with the series, it does not mean
On Wed, Aug 30, 2017 at 09:06:20AM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
>
> >> However, even with the series, it does not mean that per-monitor
> >> threads will never hang. One example is that we can stil
"Daniel P. Berrange" writes:
> On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
>> v2:
>> - fixed "make check" error that patchew reported
>> - moved the thread_join upper in monitor_data_destroy(), before
>> resources are released
>> - added one new patch (current patch 3) that fixes
On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote:
> v2:
> - fixed "make check" error that patchew reported
> - moved the thread_join upper in monitor_data_destroy(), before
> resources are released
> - added one new patch (current patch 3) that fixes a nasty risk
> condition with IOWatc
v2:
- fixed "make check" error that patchew reported
- moved the thread_join upper in monitor_data_destroy(), before
resources are released
- added one new patch (current patch 3) that fixes a nasty risk
condition with IOWatchPoll. Please see commit message for more
information.
- added a g_
55 matches
Mail list logo
