Hi Tvrtko,
[1]
> > + /*
> > + * Loop over all available slices and assign each a user engine.
> > + *
> > + * With 1 engine (ccs0):
> > + * slice 0, 1, 2, 3: ccs0
> > + *
> > + * With 2 engines (ccs0, ccs1):
> > + * slice 0, 2: ccs0
> > + * slice 1, 3: ccs1
> > + *
> > + * With 4 engines (ccs0, ccs1, ccs2, ccs3):
> > + * slice 0: ccs0
> > + * slice 1: ccs1
> > + * slice 2: ccs2
> > + * slice 3: ccs3
> > + *
> > + * Since the number of slices and the number of engines is
> > + * known, and we ensure that there is an exact multiple of
> > + * engines for slices, the double loop becomes a loop over each
> > + * slice.
> > + */
> > + for (i = num_slices / num_engines; i < num_slices; i++) {
> > + struct intel_engine_cs *engine;
> > + intel_engine_mask_t tmp;
> > +
> > + for_each_engine_masked(engine, gt, ALL_CCS(gt), tmp) {
> > + /* If a slice is fused off, leave disabled */
> > + while (!(CCS_MASK(gt) & BIT(slice)))
> > + slice++;
> > +
> > + mode &= ~XEHP_CCS_MODE_CSLICE(slice,
> > XEHP_CCS_MODE_CSLICE_MASK);
> > + mode |= XEHP_CCS_MODE_CSLICE(slice, engine->instance);
> > +
> > + /* assign the next slice */
> > + slice++;
> > + }
> > + }
> > +
> > + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, mode);
> > +}
> > +
> > +void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > +{
> > + mutex_lock(>->ccs.mutex);
> > + __intel_gt_apply_ccs_mode(gt);
> > + mutex_unlock(>->ccs.mutex);
> > +}
> > +
> > +void intel_gt_init_ccs_mode(struct intel_gt *gt)
> > +{
> > + mutex_init(>->ccs.mutex);
> > + gt->ccs.mode = 1;
>
> What is '1'? And this question carries over to the sysfs interface in the
> following patch - who will use it and where it is documented how to use it?
The value '1' is explained in the comment above[1] and in the
comment below[2]. Maybe we should give it an enum meaning? But
that would be something like CCS_MODE_1/2/4, I thinks
ccs.mode = 1/2/4 is more understandable.
> Also, should this setting somehow be gated by an applicable platform? Or if
> not on setting then when acting on it in __intel_gt_apply_ccs_mode?
>
> Creation of sysfs files as well should be gated by platform too in the
> following patch?
The idea of this series is to disable the CCS load balancing
(which automatically chooses between mode 1/2/4) and used the
a fixed scheme chosen by the user.
(I'm preparing v3 as Chris was so kind to recommend some changes
offline)
Thanks,
Andi
[2]
> > + /*
> > + * Track fixed mapping between CCS engines and compute slices.
> > + *
> > + * In order to w/a HW that has the inability to dynamically load
> > + * balance between CCS engines and EU in the compute slices, we have to
> > + * reconfigure a static mapping on the fly. We track the current CCS
> > + * configuration (set by thr user through a sysfs interface) and compare
> > + * it against the current CCS_MODE (which maps CCS engines to compute
> > + * slices). If there is only a single engine selected, we can map it to
> > + * all available compute slices for maximal single task performance
> > + * (fast/narrow). If there are more then one engine selected, we have to
> > + * reduce the number of slices allocated to each engine (wide/slow),
> > + * fairly distributing the EU between the equivalent engines.
> > + */
> > + struct {
> > + struct mutex mutex;
> > + u32 mode;
> > + } ccs;
