On 2018-01-24 12:01 PM, Michal Hocko wrote: > On Wed 24-01-18 11:27:15, Michel Dänzer wrote: >> On 2018-01-24 10:28 AM, Michal Hocko wrote: > [...] >>> So how exactly then helps to kill one of those processes? The memory >>> stays pinned behind or do I still misunderstand? >> >> Fundamentally, the memory is only released once all references to the >> BOs are dropped. That's true no matter how the memory is accounted for >> between the processes referencing the BO. >> >> >> In practice, this should be fine: >> >> 1. The amount of memory used for shared BOs is normally small compared >> to the amount of memory used for non-shared BOs (and other things). So >> regardless of how shared BOs are accounted for, the OOM killer should >> first target the process which is responsible for more memory overall. > > OK. So this is essentially the same as with the normal shared memory > which is a part of the RSS in general.
Right. >> 2. If the OOM killer kills a process which is sharing BOs with another >> process, this should result in the other process dropping its references >> to the BOs as well, at which point the memory is released. > > OK. How exactly are those BOs mapped to the userspace? I'm not sure what you're asking. Userspace mostly uses a GEM handle to refer to a BO. There can also be userspace CPU mappings of the BO's memory, but userspace doesn't need CPU mappings for all BOs and only creates them as needed. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
