[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin
On Tue, 2018-04-10 at 21:03 +0200, Olaf Hering wrote: > On Tue, Apr 10, Dario Faggioli wrote: > > > As said, its cpus= and cpus_soft=, and you probably just need > > cpus="node:1" > > cpus_soft="node:1" > > Or, even just: > > cpus="node:1" > > as, if soft-affinity is set to be equal to hard, it is just > > ignored. > > Well, that was a noop. But xl.cfg states "nodes:0-3,^node:2", so this > should work: > cpus="nodes:3,^node:0" > cpus_soft="nodes:3,^node:0" > Well, but "nodes:0-3,^node:2" is a way to say that you want nodes 0, 1 and 3. I.e., you are defining a set made up of 0,1,2,3, and then you remove 2. With "nodes:3,^node:0", you're saying that you want node 3, but not node 0. I.e., basically, you are creating a set with 3 in it, and then trying to remove 0... I agree this is not technically wrong, but it does not make much sense. Why you're not using "node:3,^node:0,^node:1,^node:2" then? So, really, the way to achieve what you seem to me to be wanting to achieve is: cpus="node:3" All that being said, yes, "nodes:3,^node:0" should work (and behave exactly as "node:3" :-) ). And in fact... > xl create -f fv_sles12sp1.f.tst.cfg > ... parsing, at the xl level, worked, or xl itself would have errored out, with its own message. > libxl: error: libxl_sched.c:62:libxl__set_vcpuaffinity: Domain > 16:Setting vcpu affinity: Invalid argument > libxl: error: libxl_dom.c:461:libxl__build_pre: setting affinity > failed on vcpu `0' > This is xc_vcpu_setaffinity() failing with EINVAL, in libxl__set_vcpuaffinity(). > Same for nodes:2..., just nodes:1... works. > > And after some attempts, cpus="nodes:2/3" fails too. > "nodes:2/3" is not supported. > There is no indication what is invalid. > Mmm... I seem to recall having tested the parser against various corner cases and/or ill-defined input. Still, my guess is that using ^ like that (i.e., excluding something which was not there in the first place), may result in a weird/corrupted cpumask. If that is the case, it indeed would be a bug. I'll check the code tomorrow. In the meanwhile --let me repeat myself-- just go ahead with "node:2", "node:3", etc. :-D 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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |