[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 for Xen 4.7 3/4] libxl: enable per-VCPU parameter settings for RTDS scheduler
On Fri, Feb 05, 2016 at 04:59:43PM +0100, Dario Faggioli wrote: > On Fri, 2016-02-05 at 14:44 +0000, Wei Liu wrote: > > On Thu, Feb 04, 2016 at 04:50:43PM -0600, Chong Li wrote: > > > Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set > > > functions to support per-VCPU settings. > > > > > > > I will need Dario or George to review the logic of the code. > > > Sure, it's on my short TODO list. It's either going to be today or > Monday. > > > If some of the comments below don't make sense, just ask. I'm sure I > > make stupid comments at times. > > > Yeah, I'm sure you've said plenty of stupid things! ;-P ;-P > Yeah. My trick is that when I say too many stupid things people don't know which one to remember so I'm safe. :-) > > > +{ > > > + if (period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT) { > > > + if (period < 1) { > > > + LOG(ERROR, "VCPU period is out of range, " > > > + "valid values are larger than or equal to > > > 1"); > > > + return 1; /* error scheduling parameter */ > > > > Though this is internal function I would very like it to stick to > > CODING_STYLE in libxl. In this particular case, the error handling > > should be using goto and the return value should be a ERROR_* value. > > > > BTW there is no upper bound check for this value? Just asking -- I > > don't > > know enough to judge. > > > It's checked in the hypervisor. As usual, in these cases, checking in > tools as well would make things more robust, allow better error > reporting, etc, _BUT_ it would require to keep the limits in sync, > which is undesirable. > > So, as long as type-related confusion is not a possibility, I would be > ok with no checks here in libxl. > > And just to be sure that we are on the safe side wrt that: in Xen these > values are uint32, should we use uint32 here as well (in the idl, > instead of 'integer')? > > > > + } > > > + max_vcpuid = info.max_vcpu_id; > > > + > > > + if (scinfo->num_vcpus > 0) { > > > + num_vcpus = scinfo->num_vcpus; > > > + GCNEW_ARRAY(vcpus, num_vcpus); > > > + for (i = 0; i < num_vcpus; i++) { > > > + if (scinfo->vcpus[i].vcpuid < 0 || > > > + scinfo->vcpus[i].vcpuid > max_vcpuid) { > > > + LOG(ERROR, "VCPU index is out of range, " > > > + "valid values are within range from 0 > > > to %d", > > > + max_vcpuid); > > > + return ERROR_INVAL; > > > + } > > > + vcpus[i].vcpuid = scinfo->vcpus[i].vcpuid; > > > + > > > + rc = sched_rtds_validate_params(gc, > > > + scinfo->vcpus[i].period, scinfo- > > > >vcpus[i].budget, > > > + &vcpus[i].s.rtds.period, > > > &vcpus[i].s.rtds.budget); > > > + if (rc) > > > + return ERROR_INVAL; > > > + } > > > + } else { > > > + num_vcpus = max_vcpuid + 1; > > > + GCNEW_ARRAY(vcpus, num_vcpus); > > > + if (sched_rtds_validate_params(gc, scinfo- > > > >vcpus[0].period, > > > + scinfo->vcpus[0].budget, > > > > This doesn't make sense. You take this path because scinfo->num_vcpus > > is > > 0 but now you're dereferencing scinfo->vcpus[0]. Do I miss anything? > > > IIRC, the idea here may be that this is how we set all the vcpus > parameters to the same values... But I'll get back to this when > properly reviewing the series. > It's one thing that when ->num_vcpus == 0 you allocate array, it's another when the array is non-NULL but num_vcpus == 0. Such usage is bad. What if I need to iterate through the array at some point? How do you know if it is really a NULL array? Wei. > Thanks and Regards, > Dario > -- > <<This happens because I choose it to happen!>> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |