From owner-cvs-src@FreeBSD.ORG Sat May 7 09:55:07 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D71B916A4D8; Sat, 7 May 2005 09:55:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9DE743DAC; Sat, 7 May 2005 09:55:07 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j479svV3073090; Sat, 7 May 2005 09:55:02 GMT (envelope-from davidxu@freebsd.org) Message-ID: <427C9080.90808@freebsd.org> Date: Sat, 07 May 2005 17:55:12 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <200505060737.j467b2R4041476@repoman.freebsd.org> <20050507043824.P12302@delplex.bde.org> <427C10D8.9060600@freebsd.org> <20050507183626.Y1839@epsplex.bde.org> In-Reply-To: <20050507183626.Y1839@epsplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 09:55:08 -0000 Bruce Evans wrote: > Functions can be called, but they must be compiled without profiling, > and if the functions are generally used then there should be special > versions of them for profiling so that profiling of their general > use doesn't get broken. In the kernel, this is handled by putting the > special versions in whole files and using the config directive > "profiling-routine" for the whole files, and mishandled for perfmon.c > by using "profiling-routine" for this file although the functions in it > are generally used. In userland, for mcount() itself, this is handled > by compiling mcount.c without profiling. > First, my commit does not make it worse than before, there are two lines: if (p->state != GMON_PROF_ON) return; which already added a bandaid. 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. > 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. > Functions can be called, but they must be compiled without profiling, > and if the functions are generally used then there should be special > versions of them for profiling so that profiling of their general > use doesn't get broken. In the kernel, this is handled by putting the > special versions in whole files and using the config directive > "profiling-routine" for the whole files, and mishandled for perfmon.c > by using "profiling-routine" for this file although the functions in it > are generally used. In userland, for mcount() itself, this is handled > by compiling mcount.c without profiling. > >> Also, signal handler will cause mcount to be reentered >> with same thread, so we have to disable signal, but you know I can >> not call other functions to disable signal(I don't know how to >> handle this for M:N threads). so I don't know how to fix all these >> problems. > > > Hmm, the problem is very old for signals, and the using busy state is > a quick fix for the problem that only works for the unthreaded case. > sigprocmask(2) can be used to disable signals -- mcount() just needs > to call a version of it compiled without profiling -- but this would > be inefficient in the same way as making syscalls to block rescheduling. > > it N layers deep. > > > > > More ideas for bandaids: > - keep a count of calls to mcount() and report it later > - don't give up on flat profiling. It is easy to increment th > More ideas for bandaids: > - keep a count of calls to mcount() and report it later > - don't give up on flat profiling. It is easy to increment the counters > atomically. > > Bruce > > > Sorry, I have no plan to fix the old nasty problem, you lose.