Messages in this thread | | | Date | Fri, 19 May 2006 21:15:12 +0200 | Subject | Re: [PATCH] 2-ptrace_multi | From | (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/
| |