Re: [PATCH v2 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

From: Dario Faggioli <dfaggioli@suse.com>
To: George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay
Date: Wed, 28 Feb 2018 16:17:42 +0100	[thread overview]
Message-ID: <1519831062.9145.10.camel@suse.com> (raw)
In-Reply-To: <1bcdf046-581e-d055-c954-80ddcb45451f@citrix.com>

[-- Attachment #1.1: Type: text/plain, Size: 2030 bytes --]

On Wed, 2018-02-28 at 15:02 +0000, George Dunlap wrote:
> On 02/23/2018 04:41 PM, Dario Faggioli wrote:
> > From this commit on, `xenpm {set,get}-vcpu-migration-delay'
> > 
> > commands work again. But that is only for the sake of
> > backward compatibility, and their use is deprecated, in
> > favour of 'xl sched-credit -s [-c <poolid>] -m <delay>'.
> > 
> > Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
> > Acked-by: Wei Liu <wei.liu2@citrix.com>
> 
> If we cared about strict behavioral compatibility, we would modify
> the
> xenpm function to set the migration delay for all cpupools; but I
> think
> we can worry about that if anyone complains. :-)
> 
Yes, I thought about that. But, considering what would be required to
implement such behavior, as compared to how many people (as far as we
can tell, of course) use this feature, and use xenpm to change it, I
also thought we are indeed fine "waiting and seeing".

> > @@ -1087,13 +1097,17 @@ void set_vcpu_migration_delay_func(int
> > argc, char *argv[])
> >  
> >  void get_vcpu_migration_delay_func(int argc, char *argv[])
> >  {
> > -    uint32_t value;
> > +    struct xen_sysctl_credit_schedule sparam;
> > +
> > +    printf("WARNING: using xenpm for this purpose is deprecated."
> > +           " Check out `xl sched-credit -s'\n");
> 
> Should these warnings be to stderr rather than stdout, so that if
> anything is manually parsing stout it will continue to work?
> 
Again, I considered this, for that same reason. The reason why I
decided for stdout is for maximizing the chances that anyone actually
using this will see the warning (even if, e.g., they're redirecting
stderr).

But I am fine with both, actually, just let me know what's considered
best.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel