Date: Sat, 07 May 2005 17:55:12 +0800 From: David Xu <davidxu@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc/gmon mcount.c Message-ID: <427C9080.90808@freebsd.org> In-Reply-To: <20050507183626.Y1839@epsplex.bde.org> References: <200505060737.j467b2R4041476@repoman.freebsd.org> <20050507043824.P12302@delplex.bde.org> <427C10D8.9060600@freebsd.org> <20050507183626.Y1839@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?427C9080.90808>