Instead of reusing CAP_SYS_NICE. Is there any on-going efforts to unify this inside the drm cgroup controller? The controller I'm referring to is this one currently used for setting gem buffer limits: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036026.html Is it possible that a new controller can be introduced for this purpose? On Wed, Aug 5, 2020 at 12:26 PM Yiwei Zhang <zzyiwei@xxxxxxxxxx> wrote: > > Let me add more context. On Android, systemui and launcher should be > allowed to create high priority gpu contexts while the normal random > applications must be ceiled to default priority. However, systemui and > launcher are not allowed to create realtime threads so we can't grant > them CAP_SYS_NICE. Thus either a new cgroup is needed in this case or > we add sysui/launcher into some other present cgroup for the gfx > kernel driver to distinguish. > > On Wed, Aug 5, 2020 at 4:47 AM Bas Nieuwenhuizen > <bas@xxxxxxxxxxxxxxxxxxx> wrote: > > > > I don't think we have a uniform mechanism, currently each driver > > decides on their own. > > > > For the amdgpu driver we check that the process either has > > CAP_SYS_NICE or is the DRM master. > > > > On Wed, Aug 5, 2020 at 9:14 AM Yiwei Zhang <zzyiwei@xxxxxxxxxx> wrote: > > > > > > Hi friends, > > > > > > For Vulkan/EGL, upon creating gpu contexts, applications can ask for a > > > system-wide higher priority levels via VK_EXT_global_priority or > > > EGL_IMG_context_priority extensions. > > > > > > I'm curious if we have certain rules(some form of process privilege > > > check) in the kernel to limit non-privileged ones to never go beyond > > > default system-wide gpu scheduling priority. (e.g. not allow random > > > app processes to contend the GPU queues repeatedly/infinitely with > > > high/realtime priorities) > > > > > > Many thanks, > > > Yiwei - from Android Platform Graphics Team > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
