Hi Steven, On Mon, 16 Jan 2023 10:30:21 +0000 Steven Price <steven.price@xxxxxxx> wrote: > On 04/01/2023 13:03, Boris Brezillon wrote: > > Hello, > > > > Here's an attempt at exposing some memory usage stats through fdinfo, > > which recently proved useful in debugging a memory leak. Not entirely > > sure the name I chose are accurate, so feel free to propose > > alternatives, and let me know if you see any other mem-related stuff > > that would be interesting to expose. > > Sorry it's taken me a while to look at this - I'm still working through > the holiday backlog. > > The names look reasonable to me, and I gave this a quick spin and it > seemed to work (the numbers reported looks reasonable). As Daniel > suggested it would be good if some of the boiler plate fdinfo code could > be moved to generic code (although to be fair there's not much here). > > Of course what we're missing is the 'engine' usage information for > gputop - it's been on my todo list of a while, but I'm more than happy > for you to do it for me ;) It's somewhat more tricky because of the > whole 'queuing' on slots mechanism that Mali has. But we obviously > shouldn't block this memory implementation on that, it can be added > afterwards. Yeah, we've been discussing this drm-engine-xxx feature with Chris, and I was telling him there's no easy way to get accurate numbers when _NEXT queuing is involved. It all depends on whether we're able to process the first job DONE interrupt before the second one kicks in, and even then, we can't tell for sure for how long the second job has been running when we get to process the first job interrupt. Inserting WRITE_JOB(CYCLE_COUNT) before a job chain is doable, but inserting it after isn't, and I'm not sure we want to add such tricks to the kernel driver anyway. Don't know if you have any better ideas. If not, I guess we can leave with this inaccuracy and still expose drm-engine-xxx... Regards, Boris
