Re: [PATCH] 2-ptrace_multi

From: Renzo Davoli
Date: Fri May 19 2006 - 15:19:13 EST

for the sake of completeness here are the numbers:

This was the previous result.
> (test computer=tibook G4 1Ghz)
> Umview+unreal test module/NO PTRACE_MULTI/NO PTRACE_SYSVM
> $ time cp /unreal/usr/src/linux-source-2.6.16.tar.bz2 /tmp
> real 0m22.626s
> user 0m0.000s
> sys 0m0.448s

This operation cannot use /proc/<pid>/mem as there is a "read" from
the virtual file system that has to write the buffer value into the
ptraced process ("cp") memory.

Let us try the reverse op.

Umview+unreal test module/NO PTRACE_MULTI/NO PTRACE_SYSVM (PTRACE, old
$ time cp /usr/src/linux-source-2.6.16.tar.bz2 /unreal/tmp
real 0m16.039s
user 0m0.000s
sys 0m0.208s

****YOUR PROPOSAL WITHOUT/WITH SYSVM (that patch is independent).
Umview+unreal test module/NO PTRACE_MULTI/NO PTRACE_SYSVM (using
$ time cp /usr/src/linux-source-2.6.16.tar.bz2 /unreal/tmp
real 0m1.649s
user 0m0.000s
sys 0m0.172s

Umview+unreal test module/NO_PTRACE_MULTI PTRACE_SYSVM (using
$ time cp /usr/src/linux-source-2.6.16.tar.bz2 /unreal/tmp
real 0m1.185s
user 0m0.004s
sys 0m0.188s

****OUR PROPOSAL (PTRACE_MULTI instead of /proc/<pid>/mem (WO/W SYSVM)
Umview+unreal test module PTRACE_MULTI/NO PTRACE_SYSVM
$ time cp /usr/src/linux-source-2.6.16.tar.bz2 /unreal/tmp
real 0m1.500s
user 0m0.004s
sys 0m0.244s

Umview+unreal test module PTRACE_MULTI/PTRACE_SYSVM
$ time cp /usr/src/linux-source-2.6.16.tar.bz2 /unreal/tmp
real 0m0.983s
user 0m0.008s
sys 0m0.148s

All the experiments have been done three times. This is the best time
(always the third); the results would have had the same significance
taking the first or the second run figures, the difference in time would have
been a bit higher.

Anyway I think I'll put this possibility (to use /proc/<pid>/mem) inside umview
source code.
It is a speedup for umview on unpatched kernel, just a one way speedup,
but it can help. Thank you for the hint.
I think that our patch(es) would be useful anyway as the solution you
propose is not a solution at all.
In the best approximation this is a workaround that covers part of the
problems with almost the same (a bit poorer) performance.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at