> Date: Thu, 27 Jul 2017 17:59:00 +0200 > From: Martin Pieuchot <[email protected]> > > On 26/07/17(Wed) 13:13, Mark Kettenis wrote: > > > Date: Wed, 26 Jul 2017 12:11:31 +0200 > > > From: Martin Pieuchot <[email protected]> > > > > > > On 24/07/17(Mon) 23:41, Laurence Tratt wrote: > > > > On Sun, Jul 23, 2017 at 11:32:06PM +0100, Laurence Tratt wrote: > > > > > > > > > extsmaild (http://tratt.net/laurie/src/extsmail/) appears to be > > > > > causing > > > > > the final panic, but given that it's just in a "wake every 60 > > > > > seconds > > > > > and see if new files have appeared in a directory" loop, I'm not > > > > > sure > > > > > why. > > > > > > > > I've now triggered another crash, this time without extsmaild (or > > > > Iridium) > > > > running. The trace is here: > > > > > > > > https://imagebin.ca/v/3UWOneXfuSWQ > > > > > > > > The "culprit" process is now mutt, but the panic is still "out of space > > > > in > > > > kmem_map" and the trace seems to be in ufs_readdir. > > > > > > I have seen the same panic message while watching a movie fullscreen > > > with mplayer yesterday. > > > > > > However as soon as CPU0 tried to enter DDB, after typing mach ddbcpu 0, > > > the machine freeze. > > > > Sounds like something is leaking memory. I don't really see any > > evidence of this on my systems. The main consumer of kmem_map "space" > > (on amd64) is malloc(9). Does vmstat -m give any clues about what is > > consuming/leaking memory? > > 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. Cheers, Mark
