[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c
On 17/06/2015 15:54, Jan Beulich wrote: > >>> On 16.06.15 at 09:09, <wei.w.wang@xxxxxxxxx> wrote: > > On 15/06/2015 20:37, Jan Beulich wrote: > >> >>> On 15.06.15 at 14:28, <wei.w.wang@xxxxxxxxx> wrote: > >> > On 15/06/2015 17:15, Jan Beulich wrote: > >> >> >>> On 15.06.15 at 02:30, <wei.w.wang@xxxxxxxxx> wrote: > >> >> > We actually want it be intel_pstate specific. If maintainers > >> >> > agree, I think renaming it to intel_pstate_policy is a good option. > >> >> > >> >> No, this name is just ugly. If you need driver specific data, have > >> >> a void > >> > pointer > >> >> in the generic structure; the driver can then allocate memory to > >> >> be pointed to by that, and can store there whatever private data it > needs. > >> > > >> > OK. I plan to make the following changes: > >> > > >> > 1) in cpufreq_policy, add a field - void *private_data; > >> > > >> > > >> > 2) add a new structure: > >> > struct intel_pstate_policy { > >> > unsigned int policy; > >> > } > >> > >> struct intel_pstate_private or struct intel_pstate_data please. > >> > > > > "struct perf_limits" is currently used only by intel_pstate, should we > > also move it to the intel_pstate_private struct, instead of the > cpufreq_policy? > > Yes of course - anything private to the driver should go there. Just realized that " struct perf_limits " will also need to be used in the common code (e.g. set max_perf_pct in pmstat.c), so I plan to keep it in the cpufreq_policy struct. Please let me know if you have a different opinion. Best, Wei _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |