<!DOCTYPE html><html data-lt-installed="true"><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body style="padding-bottom: 1px;"> <div class="moz-cite-prefix">On 5/14/2024 3:47 PM, Konda, SaiKishore wrote: </div> <blockquote type="cite" cite="mid:PH0PR11MB5674E8EF849E5B47A847B70594E32@PH0PR11MB5674.namprd11.prod.outlook.com"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)">  <style>@font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:11.0pt; font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;}span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:windowtext;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;}div.WordSection1 {page:WordSection1;}</style> <div class="WordSection1"> Hi <a id="OWAAMB3B24BE1CEFA408B8563DFC28E3AA050" href="mailto:himal.prasad.ghimiray@intel.com" moz-do-not-send="true"> @Ghimiray, Himal Prasad</a><o:p></o:p> What was the conclusion ? Will XE team support this ? Sysman consumers use single KMD Config and they don’t have different configs for different use cases. </div> </blockquote> I discussed with Saikishore and He will check with XPUM E2E team for usages of L0 API which are programming exclusive mode. <blockquote type="cite" cite="mid:PH0PR11MB5674E8EF849E5B47A847B70594E32@PH0PR11MB5674.namprd11.prod.outlook.com"> <div class="WordSection1"> <o:p></o:p> <o:p> </o:p> Thanks<o:p></o:p> SaiKishore<o:p></o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: Ghimiray, Himal Prasad <a class="moz-txt-link-rfc2396E" href="mailto:himal.prasad.ghimiray@intel.com"><himal.prasad.ghimiray@intel.com></a> Sent: Friday, May 10, 2024 3:14 PM To: Joonas Lahtinen <a class="moz-txt-link-rfc2396E" href="mailto:joonas.lahtinen@linux.intel.com"><joonas.lahtinen@linux.intel.com></a>; De Marchi, Lucas <a class="moz-txt-link-rfc2396E" href="mailto:lucas.demarchi@intel.com"><lucas.demarchi@intel.com></a>; Brost, Matthew <a class="moz-txt-link-rfc2396E" href="mailto:matthew.brost@intel.com"><matthew.brost@intel.com></a>; Konda, SaiKishore <a class="moz-txt-link-rfc2396E" href="mailto:saikishore.konda@intel.com"><saikishore.konda@intel.com></a> Cc: <a class="moz-txt-link-abbreviated" href="mailto:intel-xe@lists.freedesktop.org">intel-xe@lists.freedesktop.org</a>; Upadhyay, Tejas <a class="moz-txt-link-rfc2396E" href="mailto:tejas.upadhyay@intel.com"><tejas.upadhyay@intel.com></a>; Siddiqui, Ayaz A <a class="moz-txt-link-rfc2396E" href="mailto:ayaz.siddiqui@intel.com"><ayaz.siddiqui@intel.com></a> Subject: Re: [PATCH] drm/xe: Modify minimum of various scheduler timeout to 0<o:p></o:p> </div> </div> <o:p> </o:p> <div> <o:p> </o:p> </div> <div class="MsoNormal" style="text-align:center" align="center"> <hr width="98%" size="2" align="center"> </div> <div id="divRplyFwdMsg"> From: Joonas Lahtinen <<a href="mailto:joonas.lahtinen@linux.intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">joonas.lahtinen@linux.intel.com</a>> Sent: Friday, May 10, 2024 2:39:56 PM To: De Marchi, Lucas <<a href="mailto:lucas.demarchi@intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">lucas.demarchi@intel.com</a>>; Brost, Matthew <<a href="mailto:matthew.brost@intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">matthew.brost@intel.com</a>> Cc: Ghimiray, Himal Prasad <<a href="mailto:himal.prasad.ghimiray@intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">himal.prasad.ghimiray@intel.com</a>>; <a href="mailto:intel-xe@lists.freedesktop.org" moz-do-not-send="true" class="moz-txt-link-freetext">intel-xe@lists.freedesktop.org</a> <<a href="mailto:intel-xe@lists.freedesktop.org" moz-do-not-send="true" class="moz-txt-link-freetext">intel-xe@lists.freedesktop.org</a>>; Upadhyay, Tejas <<a href="mailto:tejas.upadhyay@intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">tejas.upadhyay@intel.com</a>> Subject: Re: [PATCH] drm/xe: Modify minimum of various scheduler timeout to 0 <o:p></o:p> <div> <o:p></o:p> </div> </div> <div> <div> Quoting Matthew Brost (2024-05-09 19:00:43) > On Wed, May 08, 2024 at 08:06:52AM -0500, Lucas De Marchi wrote: > > On Mon, May 06, 2024 at 07:04:47PM GMT, Himal Prasad Ghimiray wrote: > > > Remove the min/max configs and change minimum values of preemption and > > > timeslice to 0. The sysman teams must deactivate preemption and > > > timeslice to assess exclusivity mode. They depend on configuring > > > timeslice_duration_us and preempt_timeout_us to 0, ensuring these > > > values are set at their minimum. > > > > nack for now, based on this explanation. See below. > > > > > > > > Cc: Matthew Brost <<a href="mailto:matthew.brost@intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">matthew.brost@intel.com</a>> > > > Cc: Tejas Upadhyay <<a href="mailto:tejas.upadhyay@intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">tejas.upadhyay@intel.com</a>> > > > Cc: Joonas Lahtinen <<a href="mailto:joonas.lahtinen@linux.intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">joonas.lahtinen@linux.intel.com</a>> > > > Signed-off-by: Himal Prasad Ghimiray <<a href="mailto:himal.prasad.ghimiray@intel.com" moz-do-not-send="true" class="moz-txt-link-freetext">himal.prasad.ghimiray@intel.com</a>> <SNIP> > > > +++ b/drivers/gpu/drm/xe/xe_hw_engine.h > > > @@ -10,41 +10,17 @@ > > > > > > struct drm_printer; > > > > > > -#ifdef CONFIG_DRM_XE_JOB_TIMEOUT_MIN > > > -#define XE_HW_ENGINE_JOB_TIMEOUT_MIN CONFIG_DRM_XE_JOB_TIMEOUT_MIN > > > -#else > > > #define XE_HW_ENGINE_JOB_TIMEOUT_MIN 1 > > > -#endif > > > -#ifdef CONFIG_DRM_XE_JOB_TIMEOUT_MAX > > > -#define XE_HW_ENGINE_JOB_TIMEOUT_MAX CONFIG_DRM_XE_JOB_TIMEOUT_MAX > > > -#else > > > #define XE_HW_ENGINE_JOB_TIMEOUT_MAX (10 * 1000) > > > > previously one could configure a kernel with a different max. > > And now it's hardcoded. How is this better and related to the > > motivation in the commit message? > > > > is this commit doing 2 different things? > > > > 1) Removing the _MAX from config since nobody is or should change that > > 2) Modify the min value to 0... That seems weird as basically there is > > no minimum. > > This is true. Maybe I've missed some discussion but what is wrong with the previously agreed approach where KConfig would determine hard _MIN/_MAX bounds (and maybe _DEFAULT) that the kernel can work with, then there would be sysfs min/max (+ default) which the sysadmin sets as comfortable with considering the expected use-cases on the system and application then choose within those bounds (if it wants expedited hang detection for an example)? > > I'd like to hear Matt Brost's opinion on that. > > I chatted with Lucas and second his nack. The requirements for this > change are coming from sysman and are unclear. If sysman needs to set > this to 0 (akin to no maximum), why can't sysman build the kernel with a > Kconfig to allow this? This use case appears to be an HPC/AI data center > scenario in which the kernel is probably built with a non-standard > Kconfig anyway. Why can't CONFIG_DRM_*_MIN be set to zero? This needs to > be addressed clearly and publicly. I also thought we agreed on doing different build for such scenario where the interactive desktop is not expected to be used, so larger delays are more allowable. </div> </div> </div> </blockquote> So you are proposing an server only build where it can be set to zero. Regards -Ayaz <blockquote type="cite" cite="mid:PH0PR11MB5674E8EF849E5B47A847B70594E32@PH0PR11MB5674.namprd11.prod.outlook.com"> <div class="WordSection1"> <div> <div> The default build simply can't allow unlimited blocking of the HW by certain workloads in order to make sure the desktop/compositor stays operational. That can only be enabled by default build when the long-running workloads can be isolated so they won't interfere with the workloads using dma-fences. And I don't think that code exists yet. Sysman should be able to report a feature missing from the kernel if it detects that it can't set the limits wanted. This can be reported to user via error code and/or error message asking to install a different kernel build. Same strategy has been applied in the past for various kernel features like realtime/virtualization etc. Regards, Joonas > > Matt > > > > > Lucas De Marchi > > > > > -#endif > > > -#ifdef CONFIG_DRM_XE_TIMESLICE_MIN > > > -#define XE_HW_ENGINE_TIMESLICE_MIN CONFIG_DRM_XE_TIMESLICE_MIN > > > -#else > > > -#define XE_HW_ENGINE_TIMESLICE_MIN 1 > > > -#endif > > > -#ifdef CONFIG_DRM_XE_TIMESLICE_MAX > > > -#define XE_HW_ENGINE_TIMESLICE_MAX CONFIG_DRM_XE_TIMESLICE_MAX > > > -#else > > > +#define XE_HW_ENGINE_TIMESLICE_MIN 0 > > > #define XE_HW_ENGINE_TIMESLICE_MAX (10 * 1000 * 1000) > > > -#endif > > > #ifdef CONFIG_DRM_XE_PREEMPT_TIMEOUT > > > #define XE_HW_ENGINE_PREEMPT_TIMEOUT CONFIG_DRM_XE_PREEMPT_TIMEOUT > > > #else > > > #define XE_HW_ENGINE_PREEMPT_TIMEOUT (640 * 1000) > > > #endif > > > -#ifdef CONFIG_DRM_XE_PREEMPT_TIMEOUT_MIN > > > -#define XE_HW_ENGINE_PREEMPT_TIMEOUT_MIN CONFIG_DRM_XE_PREEMPT_TIMEOUT_MIN > > > -#else > > > -#define XE_HW_ENGINE_PREEMPT_TIMEOUT_MIN 1 > > > -#endif > > > -#ifdef CONFIG_DRM_XE_PREEMPT_TIMEOUT_MAX > > > -#define XE_HW_ENGINE_PREEMPT_TIMEOUT_MAX CONFIG_DRM_XE_PREEMPT_TIMEOUT_MAX > > > -#else > > > +#define XE_HW_ENGINE_PREEMPT_TIMEOUT_MIN 0 > > > #define XE_HW_ENGINE_PREEMPT_TIMEOUT_MAX (10 * 1000 * 1000) > > > -#endif > > > > > > int xe_hw_engines_init_early(struct xe_gt *gt); > > > int xe_hw_engines_init(struct xe_gt *gt); > > > -- > > > 2.25.1 > > > <o:p></o:p> </div> </div> </div> </blockquote> </body> <lt-container></lt-container> </html>