On 2018-01-30 11:42 AM, Daniel Vetter wrote: > On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote: >> On 2018-01-30 10:31 AM, Daniel Vetter wrote: >> >>> I guess a good first order approximation would be if we simply charge any >>> newly allocated buffers to the process that created them, but that means >>> hanging onto lots of mm_struct pointers since we want to make sure we then >>> release those pages to the right mm again (since the process that drops >>> the last ref might be a totally different one, depending upon how the >>> buffers or DRM fd have been shared). >>> >>> Would it be ok to hang onto potentially arbitrary mmget references >>> essentially forever? If that's ok I think we can do your process based >>> account (minus a few minor inaccuracies for shared stuff perhaps, but no >>> one cares about that). >> >> Honestly, I think you and Christian are overthinking this. Let's try >> charging the memory to every process which shares a buffer, and go from >> there. > > I'm not concerned about wrongly accounting shared buffers (they don't > matter), but imbalanced accounting. I.e. allocate a buffer in the client, > share it, but then the compositor drops the last reference. I don't think the order matters. The memory is "uncharged" in each process when it drops its reference. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
