From owner-cvs-all@FreeBSD.ORG Sat May 7 14:02:54 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47E9616A4DB; Sat, 7 May 2005 14:02:54 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC48743D68; Sat, 7 May 2005 14:02:53 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j47E2qrI030735; Sun, 8 May 2005 00:02:52 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j47E2ox7020330; Sun, 8 May 2005 00:02:51 +1000 Date: Sun, 8 May 2005 00:02:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Xu In-Reply-To: <427C9080.90808@freebsd.org> Message-ID: <20050507233855.G14804@delplex.bde.org> References: <200505060737.j467b2R4041476@repoman.freebsd.org> <20050507043824.P12302@delplex.bde.org> <427C10D8.9060600@freebsd.org> <20050507183626.Y1839@epsplex.bde.org> <427C9080.90808@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gmon mcount.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 14:02:54 -0000 On Sat, 7 May 2005, David Xu wrote: > Bruce Evans wrote: > ... > I know function can be compiled without profiling. I don't think mcount > is to be used to record cpu time, it is only used for recording call graph, > cpu time is recorded by kernel's clock interrupt, if a function is called by > .mcount, its cpu time will be record by kernel, and because mcount is called > everywhere, I guess the final result will show those functions called by > mcount in gprof result, possible solution is inlining syscalls as assmeble > code in mcount. Oops, I forgot that cpu time counting is only done in mcount() for high resolution profiling (GUPROF case). High resolution profiling is still not implemented in userland though userland's mcount.c has parts of it. >> Disabling of scheduling for even system scope threads could probably >> be handled by making a syscall to do it. The syscall would have to >> be compiled without profiling. But this would be very inefficient >> and migh cause security problems (it would let a thread prevent its >> own rescheduling forever). > > I don't think we want to create security risk, userland code can lockup > kernel. The security problem could probably be handled by killing the process if it tries to delay its rescheduling for too long. High priority user processes (realtime and idletime+priority inversion) looping with signals blocked already cause similar security problems -- they don't get rescheduled in the normal way, and you can't kill them even if you have a controlling terminal for them (since they block signal) unless you happen to be running a higher priority process. Bruce