[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 03/13] x86: maintain COS to CBM mapping for each socket
>>> On 29.05.15 at 04:43, <chao.p.peng@xxxxxxxxxxxxxxx> wrote: > On Thu, May 28, 2015 at 02:17:54PM +0100, Jan Beulich wrote: >> >>> On 21.05.15 at 10:41, <chao.p.peng@xxxxxxxxxxxxxxx> wrote: >> > +static int cat_cpu_init(unsigned int cpu) >> > +{ >> > + int rc; >> > + const struct cpuinfo_x86 *c = cpu_data + cpu; >> > + >> > + if ( !cpu_has(c, X86_FEATURE_CAT) ) >> > + return 0; >> > + >> > + if ( test_bit(cpu_to_socket(cpu), cat_socket_enable) ) >> > + return 0; >> > + >> > + if ( cpu == smp_processor_id() ) >> > + do_cat_cpu_init(&rc); >> > + else >> > + on_selected_cpus(cpumask_of(cpu), do_cat_cpu_init, &rc, 1); >> >> This now being called in the context of CPU_UP_PREPARE, I can't see >> how this works at all: Neither would the CPU's cpu_data[] instance be >> initialized by that time, nor would you be able to IPI that CPU, nor can I >> see how the if() branch could ever get entered. Was this tested at all? > > Ah, yes! So it sounds really a little difficult to move the memory > allocation from CPU_STARTING to CPU_PREPARA for this case. Not sure why you talk about memory allocation again. That should be done in CPU_UP_PREPARE. But stuff that needs to happen on the CPU should happen in CPU_STARTING. The memory allocation's size depending on a CPU characteristic of course makes this a little problematic, but (I think I said so before) since we're assuming symmetry in many other places, I don't see anything wrong with you assuming symmetry here too, and hence use e.g. the boot CPU's value to determine the allocation size. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |