Not, 100%, but add:
print(" bufcache pages:", (uint64_t) pstci.psc_pgcount[PC_BCACHE],
stat.page_size);
around line 172 and re-run.
It looks to me on this limited data (and keep in mind, first this isn't exactly a well cooked pstat program and second, I can't get a breakdown within kernel dynamic) that there's been a lot of inode or direct buffer writes to the disk. There isn't currently much in the buffer cache, but I strongly suspect that that's where a good chunk of the "kernel misc" is -- free pages cached in the arena layer that don't get reported as general dynamic because they're only for buffer cache. That type of activity can also cause a bunch of filesystem metadata, which I suspect is what drove up the kern dynamic. (1.1Gb of it is just large page translation cache stuff -- it will get freed up as things garbage collect or used for new allocations... just a mid-level cache. You aren't under memory pressure, so that reclamation isn't in any hurry).
If PC_BCACHE doesn't show several Gb even with the buffer cache pstat showing only Mb (i.e. the cache has burned through several Gb of buffers but is now only a few Mb of active cache... the free buffers are being held in a cache behind _that_ (object level caching)) then I'll have to punt to getting kmeminfo output, sorry. (Well, I could try to walk you through parsing this stuff in kwdb.. but kmeminfo would be a lot easier).
