From owner-cvs-src@FreeBSD.ORG Sat May 7 09:02:30 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 2EC6216A4D8; Sat, 7 May 2005 09:02:30 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 911FD43D5A; Sat, 7 May 2005 09:02:29 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j4792SkG029391; Sat, 7 May 2005 19:02:28 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j4792Px7002715; Sat, 7 May 2005 19:02:26 +1000 Date: Sat, 7 May 2005 19:02:27 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: David Xu In-Reply-To: <427C10D8.9060600@freebsd.org> Message-ID: <20050507183626.Y1839@epsplex.bde.org> References: <200505060737.j467b2R4041476@repoman.freebsd.org> <20050507043824.P12302@delplex.bde.org> <427C10D8.9060600@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-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:02:30 -0000 On Sat, 7 May 2005, David Xu wrote: > Bruce Evans wrote: > >> On Fri, 6 May 2005, David Xu wrote: >>> ... >>> Modified files: >>> lib/libc/gmon mcount.c >>> Log: >>> Fix race by using atomic operation, with this change, both libpthread >>> and libthr now can run profiling on SMP. >>> ... >> >> Doesn't userland need to wait for mcount() to become unbusy, like the >> kernel >> does? Just returning gives broken profiling. mcount() takes a long time, >> ... >> >> I don't know exactly how to avoid deadlock in userland. The kernel >> just disables interrupts. Userland would have to stop rescheduling, >> and do this without calling mcount() or dding much overhead. Note >> ... Please trim quotes when replying so that further replies don't need to do it N layers deep. > First, this is a bandaid to avoid deadlock, the deadlock is easy > to be reproduced. That it is a bandaid should be mentioned in the log message. > Also, userland is different with kernel on profiling. if I understand > it correctly, I can not call other functions in mcount(), otherwise, > the cputime of those functions will be at top of gprof result, for > system scope thread, we can not disable rescheduling, only kernel > can do this. 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. 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). > 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. 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