Re: [PATCH v4 1/1] drm/i915: Add sysfs interface to control class-of-service

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Prathap,

On 10/15/2019 12:31 AM, Prathap Kumar Valsan wrote:
> Real-Time clients running on CPU may want to run on its own partition of
> Last-Level-Cache(LLC) to achieve isolation and to be more deterministic.
> The Intel Cache-Allocation-Technology exist on CPU to partition LLC in
> to ways and dedicate a partition to an application.
> 
> However, when LLC is shared between CPU and GPU, the workloads running
> on GPU  has no notion about this partition and can thrash the cache lines
> dedicated to a Real Time task running on CPU. To avoid this, Real-Time
> clients wants a mechanism to read the existing cache ways that GPU can
> allocate, which depends on a class-of-service(CLOS) and its associated
> cache way mask and to restrict the GPU device globally to one of the
> supported CLOS levels.
> 
> Currently GPU hardware supports four CLOS levels and  there is an
> associated way-mask for each CLOS. Each LLC MOCS register has a field
> to select the CLOS level. So in-order to globally set the GPU to a CLOS
> level, driver needs to program entire MOCS table.
> 
> Hardware supports reading supported way-mask configuration for GPU using
> a bios PCode interface. The sysfs interface has two files--llc_clos_modes
> and llc_clos. The file llc_clos_modes is read only file and will list the
> available way masks. The file llc_clos is read/write and will show the
> currently active way mask and writing a new way mask will update the
> active way mask of the GPU.
> 
> Note of Caution: Restricting cache ways using this mechanism presents a
> larger attack surface for side-channel attacks.
> 
> Example usage:
>> cat /sys/class/drm/card0/llc_clos_modes
> 0xfff 0xfc0 0xc00 0x800
> 
>> cat /sys/class/drm/card0/llc_clos
> 0xfff
> 
> Update to new clos
> echo "0x800" > /sys/class/drm/card0/llc_clos

Would it be possible to expose this bitmask associated with the active
CLOS internally for the resctrl (kernel subsystem managing IA cache
allocation) to consume? The resctrl subsystem already supports
discovering (as far as hardware exposes this) cache interference to
support cache allocation decisions but at this time the Graphics cache
interference is not discoverable. It would be valuable to the resctrl
subsystem as well as the applications interacting with it to have more
accurate interference information.

Thank you

Reinette
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux