Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Wed, 23 Jan 2002, Bruce Evans wrote: > On Sun, 20 Jan 2002, k Macy wrote: > > > Should I file a PR to track this or is that overkill? > > Yes, it would be overkill. Remind me if it's not fixed in a week or two. I tested and committed the fix. Please report any other profiling bugs for SMP. I'm mainly interested in things that work for !SMP but not even as well as possible for SMP (no attempt is made to separate stats for each CPU so all we can hope for now is proper merging of the stats). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Sun, 20 Jan 2002, k Macy wrote: > Should I file a PR to track this or is that overkill? Yes, it would be overkill. Remind me if it's not fixed in a week or two. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
Should I file a PR to track this or is that overkill?
-Kip
--- Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Sat, 19 Jan 2002, k Macy wrote:
>
> > Thanks for working on this. I was going to try
> running
> > a profiled kernel on -CURRENT and -STABLE to see
> what
> > the difference was in time distribution. On
> -STABLE
> > it built without a hitch. However, on -CURRENT I
> got
> > the following even after doing a make clean:
> >
> > ../../../libkern/mcount.c: In function `mcount':
> > ../../../libkern/mcount.c:91: `mcount_lock'
> undeclared
> > (first use in this function)
>
> The mcount_lock stuff apparently never even
> compiled. It is only used
> for the !GUPROF && SMP case, but it cannot work in
> that case since
> mcount_lock is not declared. Unfortunately, LINT
> only tests the GUPROF
> case, which compiles but is even more broken at
> runtime in the SMP
> case. GUPROF worse fine in the !SMP case and should
> be non-optional
> (it gives about 10 times as much resolution as
> PROF on current
> machines, instead of only 1000 times as much as on
> 486's when it was
> written).
>
> This fix has not been tested. It has some chance of
> working, because
> RELENG_4 uses similar code. However, it is
> certainly broken if the
> atomic functions that it calls are not inlined (then
> the functions will
> call MCOUNT_ENTER() on entry). I think this only
> happens if mcount.c
> is compiled with -O0. This bug is missing in
> RELENG_4 too.
>
> %%%
> Index: profile.h
>
===
> RCS file:
> /home/ncvs/src/sys/i386/include/profile.h,v
> retrieving revision 1.25
> diff -u -2 -r1.25 profile.h
> --- profile.h 30 Oct 2001 15:04:57 - 1.25
> +++ profile.h 20 Jan 2002 06:05:24 -
> @@ -65,4 +65,5 @@
> #define MCOUNT_DECL(s) u_long s;
> #ifdef SMP
> +extern int mcount_lock;
> #define MCOUNT_ENTER(s) { s = read_eflags();
> disable_intr(); \
> while (!atomic_cmpset_acq_int(&mcount_lock,
> 0, 1)) \
> %%%
>
> Bruce
>
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Sat, 19 Jan 2002, k Macy wrote:
> Thanks for working on this. I was going to try running
> a profiled kernel on -CURRENT and -STABLE to see what
> the difference was in time distribution. On -STABLE
> it built without a hitch. However, on -CURRENT I got
> the following even after doing a make clean:
>
> ../../../libkern/mcount.c: In function `mcount':
> ../../../libkern/mcount.c:91: `mcount_lock' undeclared
> (first use in this function)
The mcount_lock stuff apparently never even compiled. It is only used
for the !GUPROF && SMP case, but it cannot work in that case since
mcount_lock is not declared. Unfortunately, LINT only tests the GUPROF
case, which compiles but is even more broken at runtime in the SMP
case. GUPROF worse fine in the !SMP case and should be non-optional
(it gives about 10 times as much resolution as PROF on current
machines, instead of only 1000 times as much as on 486's when it was
written).
This fix has not been tested. It has some chance of working, because
RELENG_4 uses similar code. However, it is certainly broken if the
atomic functions that it calls are not inlined (then the functions will
call MCOUNT_ENTER() on entry). I think this only happens if mcount.c
is compiled with -O0. This bug is missing in RELENG_4 too.
%%%
Index: profile.h
===
RCS file: /home/ncvs/src/sys/i386/include/profile.h,v
retrieving revision 1.25
diff -u -2 -r1.25 profile.h
--- profile.h 30 Oct 2001 15:04:57 - 1.25
+++ profile.h 20 Jan 2002 06:05:24 -
@@ -65,4 +65,5 @@
#defineMCOUNT_DECL(s) u_long s;
#ifdef SMP
+extern int mcount_lock;
#defineMCOUNT_ENTER(s) { s = read_eflags(); disable_intr(); \
while (!atomic_cmpset_acq_int(&mcount_lock, 0, 1)) \
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
