Date: Thu, 21 Jan 2016 11:52:24 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Mark Johnston <markj@FreeBSD.org>, Ravi Pokala <rpokala@mac.com> Cc: Adrian Chadd <adrian.chadd@gmail.com>, Andriy Voskoboinyk <avos@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "svn-src-all@freebsd.org" <svn-src-all@FreeBSD.org>, "svn-src-head@freebsd.org" <svn-src-head@FreeBSD.org> Subject: Re: svn commit: r294471 - head/sys/dev/usb/wlan Message-ID: <56A0AA58.3070704@FreeBSD.org> In-Reply-To: <20160121012825.GA9303@wkstn-mjohnston.west.isilon.com> References: <201601202327.u0KNR2Hh066219@repo.freebsd.org> <CAJ-Vmom-nORRCZx6YyhH0LJxcOUTuFfMkVsjOczNZiL-TEbsVA@mail.gmail.com> <4FBE9133-AB30-4D30-A298-1742952700C5@panasas.com> <20160121012825.GA9303@wkstn-mjohnston.west.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56A0AA58.3070704>