qemu-s390x
[Top][All Lists]
Advanced

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

Re: [qemu-s390x] [PATCHv4 2/4] qmp: add query-cpus-fast


From: Dr. David Alan Gilbert
Subject: Re: [qemu-s390x] [PATCHv4 2/4] qmp: add query-cpus-fast
Date: Fri, 16 Feb 2018 15:38:00 +0000
User-agent: Mutt/1.9.2 (2017-12-15)

* Eric Blake (address@hidden) wrote:
> On 02/16/2018 08:49 AM, Viktor Mihajlovski wrote:
> 
> > > 
> > > The HMP changes are non-trivial compared to v3, so I might have dropped
> > > all R-b and Acked-by to ensure they are looked at again.
> > > 
> > > In fact,...
> > > 
> 
> > > > -
> > > > -        if (cpu->value->CPU == monitor_get_cpu_index()) {
> > > > -            active = '*';
> > > > -        }
> > > 
> > > The old code was doing multiple things - it was telling you the current
> > > HMP cpu (HMP has 'cpu' with no QMP counterpart, but if you are using
> > > HMP, knowing which cpu is the active target for future HMP commands that
> > > depend on the active target, this bit of information is important),
> 
> > > 
> > Thanks for the patience. I'll respin with the r/a-b's on patch 2/4
> > removed, but want to verify first that I can get the active cpu without
> > triggering cpu_synchronize_state via monitor_get_cpu_index...
> 
> What does it matter?  HMP is not the time-critical interface like QMP, so
> even if it has to synchronize things, you're no worse off than you were
> before when using HMP.

I guess it's not obvious that mon_get_cpu_index has that side effect;
although I can see why it's there since it guarantees correctness of all
the HMP data with one call; a comment might be nice to point it out.

But yes, I agree the performance cost there doesn't worry me for HMP.

Dave

> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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