Messages in this thread | | | Date | Sat, 20 May 2006 17:39:59 -0400 | From | Jeff Dike <> | Subject | Re: [PATCH] 2-ptrace_multi |
| |
On Sat, May 20, 2006 at 08:30:20PM +0200, Renzo Davoli wrote: > Let me point out that PTRACE_MULTI is not only related to memory access. > We are using PTRACE_MULTI also to store the registers and restart the > execution of the ptraced process with a single syscall. > This is very effective when umview runs on a ppc32 architecture. In > fact, PPC_PTRACE_{G,S}ETREGS do not exist for that architecture > (IMHO there is no evident reason for that). Without PTRACE_MULTI each register > must be read/written individually by a PTRACE_{PEEK,POKE}USER(*)
Wouldn't the obvious fix be to implement [GS]ETREGS for arches that don't have them?
> PTRACE_MULTI can be also used to optimize many other virtualized calls, > e.g. to read/write all the buffers for a readv/writev/recvmsg/sendmsg > call at once.
Here, I bet the data copying cost dominates the system call, and the syscall overhead is minimal.
Jeff - 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/
| |