On Tue, Sep 3, 2019 at 5:20 AM Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Tue, Sep 3, 2019 at 10:24 AM Koenig, Christian > <Christian.Koenig@xxxxxxx> wrote: > > > > Am 03.09.19 um 10:02 schrieb Daniel Vetter: > > > On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote: > > >> With this RFC v4, I am hoping to have some consensus on a merge plan. I believe > > >> the GEM related resources (drm.buffer.*) introduced in previous RFC and, > > >> hopefully, the logical GPU concept (drm.lgpu.*) introduced in this RFC are > > >> uncontroversial and ready to move out of RFC and into a more formal review. I > > >> will continue to work on the memory backend resources (drm.memory.*). > > >> > > >> The cover letter from v1 is copied below for reference. > > >> > > >> [v1]: https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html > > >> [v2]: https://www.spinics.net/lists/cgroups/msg22074.html > > >> [v3]: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036026.html > > > So looking at all this doesn't seem to have changed much, and the old > > > discussion didn't really conclude anywhere (aside from some details). > > > > > > One more open though that crossed my mind, having read a ton of ttm again > > > recently: How does this all interact with ttm global limits? I'd say the > > > ttm global limits is the ur-cgroups we have in drm, and not looking at > > > that seems kinda bad. > > > > At least my hope was to completely replace ttm globals with those > > limitations here when it is ready. > > You need more, at least some kind of shrinker to cut down bo placed in > system memory when we're under memory pressure. Which drags in a > pretty epic amount of locking lols (see i915's shrinker fun, where we > attempt that). Probably another good idea to share at least some > concepts, maybe even code. I am still looking into your shrinker suggestion so the memory.* resources are untouch from RFC v3. The main change for the buffer.* resources is the removal of buffer sharing restriction as you suggested and additional documentation of that behaviour. (I may have neglected mentioning it in the cover.) The other key part of RFC v4 is the "logical GPU/lgpu" concept. I am hoping to get it out there early for feedback while I continue to work on the memory.* parts. Kenny > -Daniel > > > > > Christian. > > > > > -Daniel > > > > > >> v4: > > >> Unchanged (no review needed) > > >> * drm.memory.*/ttm resources (Patch 9-13, I am still working on memory bandwidth > > >> and shrinker) > > >> Base on feedbacks on v3: > > >> * update nominclature to drmcg > > >> * embed per device drmcg properties into drm_device > > >> * split GEM buffer related commits into stats and limit > > >> * rename function name to align with convention > > >> * combined buffer accounting and check into a try_charge function > > >> * support buffer stats without limit enforcement > > >> * removed GEM buffer sharing limitation > > >> * updated documentations > > >> New features: > > >> * introducing logical GPU concept > > >> * example implementation with AMD KFD > > >> > > >> v3: > > >> Base on feedbacks on v2: > > >> * removed .help type file from v2 > > >> * conform to cgroup convention for default and max handling > > >> * conform to cgroup convention for addressing device specific limits (with major:minor) > > >> New function: > > >> * adopted memparse for memory size related attributes > > >> * added macro to marshall drmcgrp cftype private (DRMCG_CTF_PRIV, etc.) > > >> * added ttm buffer usage stats (per cgroup, for system, tt, vram.) > > >> * added ttm buffer usage limit (per cgroup, for vram.) > > >> * added per cgroup bandwidth stats and limiting (burst and average bandwidth) > > >> > > >> v2: > > >> * Removed the vendoring concepts > > >> * Add limit to total buffer allocation > > >> * Add limit to the maximum size of a buffer allocation > > >> > > >> v1: cover letter
