qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v2 4/8] QAPI: new QMP command option "without-bql"


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [RFC v2 4/8] QAPI: new QMP command option "without-bql"
Date: Fri, 8 Sep 2017 18:38:10 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

* Peter Xu (address@hidden) wrote:
> On Fri, Aug 25, 2017 at 10:14:12AM +0100, Dr. David Alan Gilbert wrote:
> > * Peter Xu (address@hidden) wrote:
> > > On Thu, Aug 24, 2017 at 07:37:32AM +0800, Fam Zheng wrote:
> > > > On Wed, 08/23 18:44, Dr. David Alan Gilbert wrote:
> > > > > * Peter Xu (address@hidden) wrote:
> > > > > > Introducing this new parameter for QMP commands in general to mark 
> > > > > > out
> > > > > > when the command does not need BQL.  Normally QMP command 
> > > > > > executions are
> > > > > > done with the protection of BQL in QEMU.  However the truth is that 
> > > > > > not
> > > > > > all the QMP commands require the BQL.
> > > > > > 
> > > > > > This new parameter provides a way to allow QMP commands to run in
> > > > > > parallel when possible, without the contention on the BQL.
> > > > > > 
> > > > > > Since the default value of "without-bql" is still false, so now all 
> > > > > > QMP
> > > > > > commands are still protected by BQL still.
> > > > > > 
> > > > > > Signed-off-by: Peter Xu <address@hidden>
> > > > > 
> > > > > We should define what a 'without-bql' command is allowed to do:
> > > > >    'Commands that have without-bql set _may_ be called without the bql
> > > > >    being taken.  They must not take the bql or any other lock that may
> > > > >    become dependent on the bql.'
> > > 
> > > Sure.
> > > 
> > > > >    (Do we need to say anything about RCU?)
> > > 
> > > Could I ask how is RCU related?
> > 
> > My definition above said that anything declared without bql couldn't
> > take the bql, so couldn't block on any other thread holding the bql.
> > But is our command allowed to use synchronize_rcu or rcu_read_lock
> > that could wait for or block other threads doing rcu stuff?
> > Because if it did is there any guarantee that it wouldn't block?
> 
> I see.  Shall we just ignore RCU for now?  Since currently I don't see
> a real synchronize_rcu() user yet in QEMU, except the RCU thread.  And
> rcu_read_lock() should not block itself, so IMHO calling it only in
> monitor command handlers should always be fine?

Yes, I think you're right that the rcu_read_lock is OK; just something
to keep in mind.

Dave

> > 
> > 
> > > 
> > > > > 
> > > > > Also, 'no-bql' is shorter :-)
> > > > 
> > > > Or rather "need-bql" that defaults to true to avoid double negative 
> > > > (TM) with
> > > > "no-bql = false"?
> > > 
> > > Ok let me use "need-bql". :)
> > 
> > Fine by me.
> 
> I'm switching to "need-bql" for QMP only, and used "no-bql" in HMP,
> since I failed to find a good way to init mon_cmd_t field to true by
> default.
> 
> -- 
> Peter Xu
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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