Re: problem with mmap over nfs

[Fabio Brugnara <brugnara@itc.it>]

On Fri, May 06, 2005 at 04:54:46AM -0700, Andrew Morton wrote:
>
> Could you please generate a kernel profile?
>
> - Compile with CONFIG_PROFILING
>
> - Start the workload, wait for steady state.
>
> - As root, run:
>
> #!/bin/sh
>
> SM=/boot/System.map
> TIMEFILE=/tmp/prof.time
> readprofile -r
> sleep 10
> readprofile -n -v -m $SM | sort -n +2 | tail -40 | tee $TIMEFILE >&2
>
> (make sure that /boot/System.map is from the currently-running kernel)
>
> More in Documentation/basic_profiling.txt
>
>
>
> Even better, learn to drive oprofile.  Once it's running properly I usually
> use this silly script:
>
> #!/bin/sh
> opcontrol --stop
> opcontrol --shutdown
> rm -rf /var/lib/oprofile
> opcontrol --vmlinux=/boot/vmlinux-$(uname -r)
> opcontrol --start-daemon
> opcontrol --start
> sleep 10
> opcontrol --stop
> opcontrol --shutdown
> opreport -l /boot/vmlinux-$(uname -r) | head -50

Hi Andrew,

The short story:

Alarm is over. Everything works perfectly with 2.6.11.

The long story:

I could not directly do what was suggested, so I went for help to one of
our sysadmin. He installed oprofile and everything, but discovered that we
could not use it, because we didn't have the vmlinux image of the running
kernel, only vmlinuz.  After trying to recover vmlinux from vmlinuz and
discovering that it's not possible, he decided to recompile the kernel.
But, since now 2.6.11 is released, he decided also to try the latest
version.  Well, when running under 2.6.11 the strange phenomenon of
excessive system usage does not appear anymore. What we observed was
therefore just another symptom of some bug (who knows what ... ) that was
already known and fixed.

best regards,
thank you again for your attention,
Fabio

PS: just to be precise:

the kernel that had the problem was:

$ uname -r
2.6.10-1.741_FC3smp

the kernel that is now working well is:

$ uname -r
2.6.11-1.14.RH9smp