Re: [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

[Yi Sun <yi.y.sun@linux.intel.com>]

On 17-03-15 01:40:06, Jan Beulich wrote:
> >>> On 15.03.17 at 03:52, <yi.y.sun@linux.intel.com> wrote:
> > Sorry, I may not fully understand your meaning. My thoughts are below.
> > 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
> > 
> > 2. After that, we get valid cpumask through cpupool_domain_cpumask();
> > 
> > 3. If the actual valid cpumask changed after that, the new cpu is valid so
> >    that the context switch happens. Then 'psr_ctxt_switch_to' is called to
> >    update the new cpu's ASSOC register with the new COS ID which has been
> >    set in step 1.
> > 
> > 4. Send IPI to all cpus on cpumask got in step 2. They will update their
> >    ASSOC registers according to their domains psr_cos_ids[].
> > 
> > So I think this flow can cover all cpus which ASSOC registers need be 
> > updated.
> 
> You writing it down this way makes me realize that the IPI approach
> can't work this way at all: It leaves a time window (between 1 and 2)
> where the domain may have vCPU-s running with the wrong COS ID.
> I think pausing the vCPU is unavoidable, unless it can be explained
> that running with the wrong COS ID for a brief period of time is not
> really a problem. I do realize that the pausing approach has its own
> difficulty wrt Dom0, but I think that's solvable (e.g. by doing the
> actual work in a tasklet instead of in the context of a Dom0 vCPU).
> 
I have below thoughts.
1. We can use domain_pause for all domains except Dom0 to update COS ID.
2. PSR features are to set cache capacity for a domain. The setting to
   cache is progressively effective. When the cache setting becomes really
   effective, the time slice to schedule a domain may have passed. Moreover,
   even a wrong COS ID is used to set ASSOC, only another CBM be effective
   for a short time. In next Dom0 schedule, the correct CBM will take effect.
   So can we just leave Dom0 setting as current implementation?

Thanks,
Sun Yi

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