Re: [User-mode-linux-devel] Performance enhancement idea...

[Jeff D. <jd...@ka...>]

sa...@sk... said:
> 1. Instead of changing EAX to make the syscall do a getpid, why not
> just add 2 to the EIP to skip over the int 80? 

Because the EIP += 2 has already happened.  I think the processor bumps the ip 
to the next instruction before the current one starts executing.  When a 
process is in a system call, its eip is already bumped to the following 
instruction.

To see what's going on here, look at arch/i386/entry.S at the trace_sys label:

tracesys:
	movl $-ENOSYS,EAX(%esp)
	call SYMBOL_NAME(syscall_trace) *****
	movl ORIG_EAX(%esp),%eax
	cmpl $(NR_syscalls),%eax
	jae tracesys_exit
	call *SYMBOL_NAME(sys_call_table)(,%eax,4)
	movl %eax,EAX(%esp)		# save the return value
tracesys_exit:
	call SYMBOL_NAME(syscall_trace)
	jmp ret_from_sys_call
badsys:
	movl $-ENOSYS,EAX(%esp)
	jmp ret_from_sys_call

When the tracing thread is reading out the system call and changing it to 
getpid, the child is at the '*****' line above.  Notice that it's going to 
execute a system call, unless the syscall number is changed to be illegal, and 
that the saved eip plays no part here.

If you did fiddle the registers, they would take effect when the process 
leaves the kernel (from ret_from_sys_call) and those registers are restored.

sa...@sk... said:
> 2. Additionally, why not change that int 80 to be "ud2" or some other
> opcode that will cause a SIGILL?  When receiving a sigill, just check
> for the magic opcode and if it is set, do the syscall... this would
> have the advantage that the ptrace/c-switch overhead would be
> reduced... 

re...@cs... said:
> If the idea is to increase the performance, why not no change the "int
> $80" for a "call um_syscall". um_syscall can "communicate" when it's
> strictly necessary.

These ideas break security if tracing is turned off as a result.  A hostile 
process could unmodify itself (or generate the system call dynamically) and 
get access to the host.

That's not necessarily fatal.  We could have a slow, secure jail mode and a 
fast non-secure mode.  But I think that there are plenty of ways of speeding 
things up and keeping it secure.  I would think about putting things like this 
in after I was reasonably convinced that secure mode was about as fast as it 
was going to get, and also that relaxing security would provide noticeable 
speed gains.

If anyone is interested in starting a uml performance project, I would suggest 
the following:

Make sure that all of the system calls that uml makes into the host can't 
block.  This moves all idle time into the idle thread where it belongs, and 
where it can be more easily seen.  It also gives the kernel a chance to do 
something else.  I think this is already the case, but I haven't done the 
audit to make sure.

Profile it and see what's taking all the time and fix it. (As an aside here, 
if someone were to make profile and test coverage configurable like debugging 
is now, I would put it in :-)

Make the block driver able to have multiple operations in flight at once.  
Right now, there is a single io thread, so there can be one io in flight at a 
time.

My long-term plan for system calls is to eliminate the tracing thread 
altogether.  There are two aspects to this - making threads able to 
PTRACE_CONT and PTRACE_SYSCALL themselves, and allowing threads to intercept 
their own system calls.

Allowing threads to PTRACE_CONT and PTRACE_SYSCALL themselves would speed up 
system calls somewhat and probably significantly speed up fault handling and 
signal delivery.

Letting threads intercept their own system calls would involve adding a second 
slow system call path to the host.  This would just deliver a signal 
(SIGSYSCALL, say) to the thread, and the SIGSYSCALL handler would (in uml's 
case) enter the kernel and do the system call.

These two would eliminate context switching back and forth between the tracing 
thread and the others.  uml might have a chance of getting within reasonable 
distance of native performance at that point.

If anyone wants to start looking at the mods needed in the native kernel for 
this, we could have something to propose reasonably early in 2.5.

				Jeff