> Date: Thu, 27 Jul 2017 18:18:34 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > The only "leak" I'm seeing is the 'drmreq' pool. It grows until the > > application is closed. Note that with my fix the allocated size for > > 'drmreq' is divided by 4. So if that was the problem I might not be > > able to reproduce it. > > That might be it. The pool item size was 584 bytes. Because of the > "size * 8" in the pool implementation we end up using "large" pool > pages. Since the pool doesn't have the PR_WAITOK flag this end up > using the "interrupt safe" allocator which allocates its VAs from > kmem_map. > > After the pool_init() fix, it'll now use "small" pool pages, which are > directly mapped. So if the problem disappears we have winner. I'll > take a look anyway. The requests allocated shouldn't grow without > bound. At least I expect it to be roughle the same number as the > number of graphics executaion requests in flight, which shouldn't be > more than a couple per process.
I found no evidence for a real memory leak. So the kmem_map exhaustion probably happened during some heavy-duty rendering. So I suppose the issue is properly fixed now.