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

Re: [Xen-devel] [PATCH v2 6/9] x86/intel_pstate: the main boby of the intel_pstate driver



>>> On 02.06.15 at 05:23, <wei.w.wang@xxxxxxxxx> wrote:
> On 26/05/2015 21:58, Jan Beulich wrote
>> >>> On 13.05.16 at 09:50, <wei.w.wang@xxxxxxxxx> wrote:
>> > +    id = x86_match_cpu(intel_pstate_cpu_ids);
>> > +    if (!id)
>> > +        return -ENODEV;
>> > +
>> > +    cpu_info = (struct cpu_defaults *)id->driver_data;
>> > +
>> > +    copy_pid_params(&cpu_info->pid_policy);
>> > +    copy_cpu_funcs(&cpu_info->funcs);
>> > +    if (intel_pstate_msrs_not_valid())
>> > +        return -ENODEV;
>> > +
>> > +    all_cpu_data = xzalloc_array(struct cpudata *,
>> > + num_online_cpus());
>> 
>> This looks suspicious considering CPU hotplug, the more that this is the only
>> place it gets allocated.
> 
> I just found that "num_possible_cpus()" is currently not usable for the x86 
> code. Can we use the Xen supported max possible CPUs - NR_CPUS (usually it's 
> 256), i.e. all_cpu_data = xzalloc_array(struct cpudata *, NR_CPUS) ? 
> Since each entry is just a pointer, this won't waste too much memory.

If anything it would be nr_cpu_ids that you'd want to use here. (And
no, assuming NR_CPUS to "usually" be 256 is wrong - this is merely
the default, no more and no less).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.