On Thu, Oct 6, 2022 at 5:14 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Thu, Oct 06, 2022, Vipin Sharma wrote:
> > On Thu, Oct 6, 2022 at 12:50 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > > > +{
> > > > + cpu_set_t cpuset;
> > > > + int err;
> > > > +
> > > > + CPU_ZERO(&cpuset);
> > > > + CPU_SET(pcpu, &cpuset);
> > >
> > > To save user pain:
> > >
> > > r = sched_getaffinity(0, sizeof(allowed_mask), &allowed_mask);
> > > TEST_ASSERT(!r, "sched_getaffinity failed, errno = %d (%s)", errno,
> > > strerror(errno));
> > >
> > > TEST_ASSERT(CPU_ISSET(pcpu, &allowed_mask),
> > > "Task '%d' not allowed to run on pCPU '%d'\n");
> > >
> > > CPU_ZERO(&allowed_mask);
> > > CPU_SET(cpu, &allowed_mask);
> > >
> > > that way the user will get an explicit error message if they try to pin a vCPU/task
> > > that has already been affined by something else. And then, in theory,
> > > sched_setaffinity() should never fail.
> > >
> > > Or you could have two cpu_set_t objects and use CPU_AND(), but that seems
> > > unnecessarily complex.
> > >
> >
> > sched_setaffinity() doesn't fail when we assign more than one task to
> > the pCPU, it allows multiple tasks to be on the same pCPU. One of the
> > reasons it fails is if it is provided a cpu number which is bigger
> > than what is actually available on the host.
> >
> > I am not convinced that pinning vCPUs to the same pCPU should throw an
> > error. We should allow if someone wants to try and compare performance
> > by over subscribing or any valid combination they want to test.
>
> Oh, I'm not talking about the user pinning multiple vCPUs to the same pCPU via
> the test, I'm talking about the user, or more likely something in the users's
> environment, restricting what pCPUs the user's tasks are allowed on. E.g. if
> the test is run in shell that has been restricted to CPU8 via cgroups, then
> sched_setaffinity() will fail if the user tries to pin vCPUs to any other CPU.
I see, I will add this validation.
