[uml-devel] high-performance system calls using vsyscall

[uml-devel] high-performance system calls using vsyscall

[Young Koh]

Hi, all,

I found an old post discussing the possibility of turning a system
call into a procedure call using vsyscall. Is it really implemented in
recent versions? I tested with recent Linux/UML kernels and glibcs but
system calls don't seem that fast. so, i guess it's not implemented
yet?

-Young

From: Jeff Dike <jdike@ka...>
 Re: sysenter and int 80
2002-12-26 11:18
 jonsmirl@ya... said:
 > Is this new page mapping going to effect UML?
 > http://lwn.net/Articles/17931/

 Yup.

 I can use that page to turn a system call into a procedure call.  Highly
 insecure, but the performance will rock.

 				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] high-performance system calls using vsyscall

[Jeff Dike]

On Thu, Jan 12, 2006 at 12:02:16PM -0500, Young Koh wrote:
> I found an old post discussing the possibility of turning a system
> call into a procedure call using vsyscall. Is it really implemented in
> recent versions? I tested with recent Linux/UML kernels and glibcs but
> system calls don't seem that fast. so, i guess it's not implemented
> yet?

In the generic kernel (or in whatever arches have the vsyscall page),
it's used for only a small number of system calls.

In a tt-style UML, where the UML kernel is in the same address space
as the process, this could be used for all system calls, where you
would just jump from there into the UML kernel.  I think you would
have to fiddle libc to make all of the system calls fo this.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] high-performance system calls using vsyscall

[Blaisorblade]

On Friday 13 January 2006 00:38, Jeff Dike wrote:
> On Thu, Jan 12, 2006 at 12:02:16PM -0500, Young Koh wrote:
> > I found an old post discussing the possibility of turning a system
> > call into a procedure call using vsyscall. Is it really implemented in
> > recent versions? I tested with recent Linux/UML kernels and glibcs but
> > system calls don't seem that fast. so, i guess it's not implemented
> > yet?

> In the generic kernel (or in whatever arches have the vsyscall page),
> it's used for only a small number of system calls.

No, wrong - on x86 it's used for everything, depending on userspace (it's 
replacing int 0x80 with sysenter). For some reason, on x86-64 it was that 
way, but it switched to what you say (implementing only a few syscalls 
directly in userspace).

> In a tt-style UML, where the UML kernel is in the same address space
> as the process, this could be used for all system calls, where you
> would just jump from there into the UML kernel.

1st, TT mode is kept there only until SKAS0 will be damn stable (it seems 
we're probably reaching that, no foreseen problems, except maybe my new TLS 
code doesn't work for SKAS0 yet IMHO), and because it's the only SMP 
supporting mode.

However, going through ptrace for interprocess comunication is far from 
optimal - using something like, say, POSIX message queues (it's a wild guess) 
would be probably faster. Something purely in userspace seems difficult. 
However, as shown below, if it's not purely in userspace ptrace will 
intercept it, so we stop any gain.

> I think you would have to fiddle libc to make all of the system calls for 
this.

No, you have to do worse - newer libc (more or less NPTL ones) link to a DSO 
which is the vsyscall page, which we can't replace. However maybe the address 
is not fixed, so we could pass the address of another vsyscall page with our 
code.

Obviously ptrace can't be disabled, as int 0x80 is still usable inside UML, 
and you must catch that. Also the normal vsyscall page is still mapped and 
could be run, so sysenter must be also caught.

Once you pass another vsyscall page to glibc, you must only write the 
implementation, distinguish the syscalls from that page (which must go in) 
from the syscalls coming from everywhere else (which must still be 
intercepted the normal way). Indeed, you still get to trace even new-style 
syscalls this way (adding an API for checking something in kernel before 
switching to the debugger is ugly, especially because we indeed must inspect 
the stack to see where the syscall come from).

> 				Jeff

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


	
	
		
___________________________________ 
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] high-performance system calls using vsyscall

[Chris Lightfoot]

On Tue, Jan 17, 2006 at 01:04:21AM +0100, Blaisorblade wrote:
    [...]
> However, going through ptrace for interprocess comunication is far from 
> optimal - using something like, say, POSIX message queues (it's a wild guess) 
> would be probably faster. Something purely in userspace seems difficult. 
> However, as shown below, if it's not purely in userspace ptrace will 
> intercept it, so we stop any gain.

http://caesious.beasts.org/~chris/tmp/20060117/msgq-pipe-signal-costs.png

(measured on 2.6.12.6, on Intel Xeon, with sending and
receiving processes bound to the same CPU).

So message queues don't win you much over pipes, but do
(significantly!) over signals.

-- 
``Oh my god, I was wrong! It was Earth all along!
  You've finally made a monkey out of me.''
  (`Stop the Planet of the Apes! I want to get off', from `The Simpsons')


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] high-performance system calls using vsyscall

[Jeff Dike]

On Tue, Jan 17, 2006 at 01:04:21AM +0100, Blaisorblade wrote:
> No, wrong - on x86 it's used for everything, depending on userspace (it's 
> replacing int 0x80 with sysenter). For some reason, on x86-64 it was that 
> way, but it switched to what you say (implementing only a few syscalls 
> directly in userspace).

Yeah, I was remembering Andrea's original proposal to implement a few system
calls entirely in userspace.

> > In a tt-style UML, where the UML kernel is in the same address space
> > as the process, this could be used for all system calls, where you
> > would just jump from there into the UML kernel.
> 
> 1st, TT mode is kept there only until SKAS0 will be damn stable (it seems 
> we're probably reaching that, no foreseen problems, except maybe my new TLS 
> code doesn't work for SKAS0 yet IMHO), and because it's the only SMP 
> supporting mode.

It has worked fine for me since I fixed that one bug.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel