On 21/01/2016 03:28, Mark Johnston wrote: > One feature that would be nice would be a way to associate KTR rings > with arbitrary objects rather than having a single global ring (or > per-CPU rings). For example, KTR_BUF lets one trace operations on > filesystem buffers, but there's no good way to find all trace records > corresponding to a given buf. At the moment one has to always include a > pointer to the buf, and then scan *all* KTR entries for the pointer of > interest while hoping that the relevant entries haven't already been > overwritten. With per-object rings, one can in effect see a "history" of > the object, whether it's a buf or a driver softc or whatever. > > Isilon has done ad-hoc implementations of this for bufs and mbufs, and > they're quite handy for debugging. With BUF_TRACKING enabled in our > kernel config, each buf contains a const char *b_records[32], and one > adds > > buf_track(bp, __func__); > > or so to various functions to record an entry in the buf when the > function is invoked. This is really similar to what KTR does already, > and I've needed to further hack up our buf tracking to include metadata > (thread IDs) that KTR already provides. And, KTR records can be > retrieved from vmcores by ktrdump -M.
Does your extension also save a stack trace? I would love to have something like that for the memory allocation and deallocation audit. -- Andriy Gapon _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "[email protected]"
