On 8 Feb 2011, at 10:37, Alan Cox wrote: >> John and I have occasionally talked about making procstat -v work on the >> kernel; conceivably it could also export a wired page count for mappings >> where it makes sense. Ideally procstat would drill in a bit and allow you >> to see things at least at the granularty of "this page range was allocated >> to UMA". > > I would certainly have found this useful on a few occasions, and would gladly > help out with implementing it. For example, it would help us in > understanding the kmem_map fragmentation caused by ZFS. That said, I'm not > sure how you will represent the case where UMA allocates physical memory > directly and uses the direct map to access it.
I agree -- in some sense, my proposal is related to, but somewhat orthogonal to, the problem Ivan is running into. We could also have a more detailed but UMA-specific inspection tool; I have a uma dumping tool in src/tools somewhere that dumps zone information, buckets, etc, for UMA types. I've used this in the past to explore mbuf alloc/free behaviour, multi-CPU imbalances in allocation, over-caching, etc. It may be time to revisit that, decide how to make it a bit more user/developer-friendly, and make it a formally supported tool as part of vmstat (which involves adding some new sysctls as well). Robert _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
