Re: [PATCH] 2-ptrace_multi

[renzo@cs.unibo.it (Renzo Davoli)]

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.

****OLD WAY
Umview+unreal test module/NO PTRACE_MULTI/NO PTRACE_SYSVM (PTRACE, old
way)
$ 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
/proc/<pid>/mem)
$ 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
/proc/<pid>/mem)
$ 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.

renzo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/