Date: Tue, 12 Jul 2005 09:55:56 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-arch@freebsd.org Cc: Peter Edwards <peadar@freebsd.org>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: ktrace and KTR_DROP Message-ID: <200507120955.58014.jhb@FreeBSD.org> In-Reply-To: <200507112056.02249.peter@wemm.org> References: <20050701132104.GA95135@freefall.freebsd.org> <20050701155757.A36905@fledge.watson.org> <200507112056.02249.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 11 July 2005 11:56 pm, Peter Wemm wrote: > On Friday 01 July 2005 08:04 am, Robert Watson wrote: > > On Fri, 1 Jul 2005, Peter Edwards wrote: > > > Ever since the introduction of a separate ktrace worker thread for > > > writing output, there's the distinct possibility that ktrace output > > > will drop requests. For some proceses, it's actually inevitable: as > > > long as the traced processes can sustain a rate of generating > > > ktrace events faster than the ktrace thread can write them, you'll > > > eventually run out of ktrace requests. > > [..] > > > One of the things I've been thinking for a few years is that I think > > I actually preferred the old model better, there processes (now > > threads) would hang a "current record" off of their process (now > > thread) structure, and fill it in as they went along. > > I much prefer the old model as well. I personally would like to have > syscall returns delayed if the outstanding writes for ktrace requests > is above a certain watermark. There have been several suggestions for > how to do this. > > This could be as simple as throttling *all* ktrace writers as they > return to userland from syscalls if the backlog is getting too large. > But probably better would be to have each process responsible for its > own writing and backlog management. ie: queue up the records to memory > just like now, and start unwinding them at a convenient location in > syscall return. If you do that then you can still drop records if you use up too many before you finally return from your system call. The patch at the start of this thread I think is the better approach as it blocks the thread once there aren't any free request tokens so that the thread will be throttled when the system gets behind, but will free run as long as the system can keep up. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507120955.58014.jhb>