Date: Wed, 17 Jan 2018 23:41:03 +0000 From: Colin Percival <cperciva@tarsnap.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327423 - in head/sys: kern sys Message-ID: <01000161067f5435-58c4c318-6d51-42e6-8a9e-b51de30864b8-000000@email.amazonses.com> In-Reply-To: <20180117230902.GP8113@FreeBSD.org> References: <201712310921.vBV9L133042419@repo.freebsd.org> <20180117230902.GP8113@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/17/18 15:09, Gleb Smirnoff wrote: > On Sun, Dec 31, 2017 at 09:21:01AM +0000, Colin Percival wrote: > C> Code for recording timestamps of events, especially function entries/exits. > C> This is a very primitive system, intended for use in measuring performance > C> during the early system boot, before more sophisticated tools like DTrace > C> or infrastructure like kernel memory allocation and mutexes are available. > > Sorry if my question is too lame and late. Why can't you use ktr(4) tracer > for that purpose? The discussion on freebsd-current also doesn't have answer. I considered it, but it wasn't a good fit for a couple reasons: 1. ktr uses a circular buffer, while (since I'm looking at the boot process) I want to fill a buffer and then stop recording. 2. I would have needed to hack up ktr in order to make it work early enough in the boot process. (Most obviously: When we enter hammer_time, trying to access 'curthread' is a Bad Idea.) Since the timestamp recording framework I needed was just a few lines of code -- all the other commits are to add the points where timestamps are recorded, and would have been needed even if I used ktr -- it seemed better to just add my own code rather than coercing ktr to do what I needed. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01000161067f5435-58c4c318-6d51-42e6-8a9e-b51de30864b8-000000>