qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] iothread: provide helpers for internal use


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 1/3] iothread: provide helpers for internal use
Date: Fri, 22 Sep 2017 11:28:08 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

On Fri, Sep 22, 2017 at 12:26:16PM +0200, Paolo Bonzini wrote:
> On 22/09/2017 12:20, Daniel P. Berrange wrote:
> > On Fri, Sep 22, 2017 at 12:18:44PM +0200, Paolo Bonzini wrote:
> >> On 22/09/2017 12:16, Stefan Hajnoczi wrote:
> >>> I suggest adding internal IOThreads alongside user-created IOThreads
> >>> instead of hiding them.  IOThread also needs a bool user_created field
> >>> and a UserCreatableClass->can_be_deleted() function:
> >>>
> >>>   static bool iothread_can_be_deleted(UserCreatable *uc)
> >>>   {
> >>>       return IOTHREAD(uc)->user_created;
> >>>   }
> >>>
> >>> This way users cannot delete internal IOThreads.
> >>>
> >>> But how should object ids be handled?  In theory existing -object
> >>> iothread,id=<id> users could use any name.  How can QEMU generate ids
> >>> for internal IOThreads without conflicting with existing users's ids?
> >>
> >> I would add an 'internal' boolean to query-iothreads' response and a new
> >> 'show-internal' boolean to the command.  This way, applications that
> >> request internal iothreads would know that the "primary key" is
> >> (internal, id) rather than just the id.
> > 
> > What is the app going to do with iothreads if it sees "internal" flag
> > set ? They have no way of knowing what part of QEMU internally is using
> > this iothread, so I don't see that they can do anything intelligent
> > once they find out they exist.
> 
> The application could apply them default settings for scheduler policy
> or CPU affinity.
> 
> Unlike the main or the I/O thread, the monitor thread doesn't interrupt
> the CPU, so it need not run at SCHED_FIFO even in real-time settings.

There's no way for the application to know that. ALl it sees is that there
is an extra unexpected IOthread created internally by QEMU. There's no way
to decide whether it nedes SCHED_FIFO or not as we've no clue what it is
being used for.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

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