From owner-svn-src-all@freebsd.org Thu Jan 21 09:53:51 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1996BA89B1C; Thu, 21 Jan 2016 09:53:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7C63A19AE; Thu, 21 Jan 2016 09:53:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA21540; Thu, 21 Jan 2016 11:53:46 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aMBw2-0007RS-8h; Thu, 21 Jan 2016 11:53:46 +0200 Subject: Re: svn commit: r294471 - head/sys/dev/usb/wlan To: Mark Johnston , Ravi Pokala References: <201601202327.u0KNR2Hh066219@repo.freebsd.org> <4FBE9133-AB30-4D30-A298-1742952700C5@panasas.com> <20160121012825.GA9303@wkstn-mjohnston.west.isilon.com> Cc: Adrian Chadd , Andriy Voskoboinyk , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" From: Andriy Gapon Message-ID: <56A0AA58.3070704@FreeBSD.org> Date: Thu, 21 Jan 2016 11:52:24 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160121012825.GA9303@wkstn-mjohnston.west.isilon.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 09:53:51 -0000 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