Re: oprofile does not correctly detect vdso regions

[Amitabha R. <ami...@gm...>]

Hi John

A pure userspace solution would not work if the VDSO regions were to
be randomized (which it is in the current 2.6 head of tree). So we
must have some kind of support in the kernel.

I've already sent a  kernel patch (to LKML and copied phil.el on it).
I sent out a cleaned up userspace patch recently to this list.
Incorporating it will cause *no incompatibility* with the kernel since
the special cookie will not be emitted unless my kernel patch is
applied. On the other hand we have to make changes to the kernel
anyway so incorporating this will make a strong case for Phil to apply
the kernel patch.

This would also be the first step to extracting symbols in the VDSO
region from the kernel and display them in the detailed report. It
would be very useful to diagnose cases like frequent syscall restarts
which seems to be happening in the experiments I am running.


In theory of course one could do something purely in userspace like
open the /proc/map file of some process (perhaps oprofile itself) and
then look for the vdso keyword. But this would not be backward
compatible with older kernels which do not mark the vdso region. Also
the /proc/map file is unreadable on some FC4 systems.

Do you have any other pure userspace solution in mind ?

Thanks
-Amitabha



On 12/14/06, John Levon <le...@mo...> wrote:
> On Mon, Dec 04, 2006 at 08:12:35PM +0530, Amitabha Roy wrote:
>
> > a) whether there is sufficient interest in this that I clean it up and
> > send it out for testing. While an application "typically" is not
> > supposed to spend too much time in that region dbench is doing that
> > for me and I think it is worthwhile to isolate the vdso region from
> > anon pages to help in such situations.
> >
> > b) Any comments on my approach to the problem.
>
> I'd prefer a user-space solution, so we don't have a new kernel/user
> incompatibility. We could default to the static location, and have
> something that exports from the kernel the location of the VDSO if
> relevant.
>
> regards
> john
>