[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080305182231.GC12629@one.firstfloor.org>
Date: Wed, 5 Mar 2008 19:22:31 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Andi Kleen <andi@...stfloor.org>, Valdis.Kletnieks@...edu,
linux-kernel@...r.kernel.org, sam@...nborg.org
Subject: Re: 2.6.25-rc3-mm1 - PROFILE_LIKELY redux..
> Yes, but both those files now have:
>
> /*
> * likely and unlikely explode when used in vdso in combination with
> * profile-likely-unlikely-macros.patch
> */
> #undef likely
> #define likely(x) (x)
> #undef unlikely
> #define unlikely(x) (x)
>
> at the top, so it'll be something else. Perhaps a `likely' snuck in via an
I see.
> inline in a header file. It would be better to add a #define DONT_DO_THAT
I think you need to do it differently. Not undef/define, but set
some symbol that is checked by the unlikely profiler and it won't
enable itself with that symbol set. Then header files would be covered too.
> at the top of arch/x86/kernel/vsyscall_64.c and
> arch/x86/vdso/vclock_gettime.c, then use that to defeat likely-profiling.
Possible. The problem is that there are now vsyscall functions in
other files too, especially hpet_64.c and tsc_64.c
Perhaps this is something that should be just checked in modpost instead.
Any external references from the vsyscall section to another section
should be flag'ed as error (cc'ed Sam in case he wants to look at that)
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists