Menu
▾
▴
user-mode-linux-devel
|
From: Chris L. <sa...@sk...> - 2000-07-07 19:44:20
|
Hello all... Currently, syscall entry requires the tracing thread to wake up, munge the registers around, and do other stuff before the syscall'ing thread continues in the kernel... I have two ideas to improve syscall performance: 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? 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... Does anyone see any problems with these suggestions? I may be interested in implementing them if not... -Chris |
|
From: Jose R. <re...@cs...> - 2000-07-07 19:57:13
|
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. For example, a getpid could be done locally. This optimization could do te umlinux even faster than the "default" Linux. Suggestions? On Fri, 7 Jul 2000, Chris Lattner wrote: > Currently, syscall entry requires the tracing thread to wake up, munge the > registers around, and do other stuff before the syscall'ing thread > continues in the kernel... I have two ideas to improve syscall > performance: > > 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? > 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... > > Does anyone see any problems with these suggestions? I may be interested > in implementing them if not... > > -Chris > > > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel > ------------------------------------------------------------------- Jose Renau Ardevol | The great things in life are what they re...@ui... | seem to be. Oscar Wilde ------------------------------------------------------------------- |
|
From: Chris L. <sa...@sk...> - 2000-07-07 20:01:08
|
The only problem is that you only have two bytes of code space to work with (int 0x80 is encoded as 0xCD 0x80), and a call takes 5? bytes... :( If there is any other useful thing to fit into two bytes... that would be cool too! -Chris On Fri, 7 Jul 2000, Jose Renau wrote: > > 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. For example, a getpid could be done locally. > > This optimization could do te umlinux even faster than the "default" > Linux. > > Suggestions? > > On Fri, 7 Jul 2000, Chris Lattner wrote: > > > Currently, syscall entry requires the tracing thread to wake up, munge the > > registers around, and do other stuff before the syscall'ing thread > > continues in the kernel... I have two ideas to improve syscall > > performance: > > > > 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? > > 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... > > > > Does anyone see any problems with these suggestions? I may be interested > > in implementing them if not... > > > > -Chris > > > > > > > > _______________________________________________ > > User-mode-linux-devel mailing list > > Use...@li... > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel > > > > ------------------------------------------------------------------- > Jose Renau Ardevol | The great things in life are what they > re...@ui... | seem to be. Oscar Wilde > ------------------------------------------------------------------- > > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel > |
|
From: Jose R. <re...@cs...> - 2000-07-07 20:06:38
|
On Fri, 7 Jul 2000, Chris Lattner wrote: > The only problem is that you only have two bytes of code space to work > with (int 0x80 is encoded as 0xCD 0x80), and a call takes 5? bytes... > > :( If there is any other useful thing to fit into two bytes... that would > be cool too! There are some tools for instrumenting code. http://www.cs.umd.edu/projects/dyninstAPI/ A small modification would make possible to change "int $80" for more elavorate code. This has to be done when the code is loaded (fs/binfmt_elf.c) but I think that it's feasable. > On Fri, 7 Jul 2000, Jose Renau wrote: > > > > > 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. For example, a getpid could be done locally. > > > > This optimization could do te umlinux even faster than the "default" > > Linux. > > > > Suggestions? > > > > On Fri, 7 Jul 2000, Chris Lattner wrote: > > > > > Currently, syscall entry requires the tracing thread to wake up, munge the > > > registers around, and do other stuff before the syscall'ing thread > > > continues in the kernel... I have two ideas to improve syscall > > > performance: > > > > > > 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? > > > 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... > > > > > > Does anyone see any problems with these suggestions? I may be interested > > > in implementing them if not... > > > > > > -Chris > > > > > > > > > > > > _______________________________________________ > > > User-mode-linux-devel mailing list > > > Use...@li... > > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel > > > > > > > ------------------------------------------------------------------- > > Jose Renau Ardevol | The great things in life are what they > > re...@ui... | seem to be. Oscar Wilde > > ------------------------------------------------------------------- > > > > > > _______________________________________________ > > User-mode-linux-devel mailing list > > Use...@li... > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel > > > ------------------------------------------------------------------- Jose Renau Ardevol | The great things in life are what they re...@ui... | seem to be. Oscar Wilde ------------------------------------------------------------------- |
|
From: Chris L. <sa...@sk...> - 2000-07-07 20:17:11
|
> > :( If there is any other useful thing to fit into two bytes... that would > > be cool too! > > There are some tools for instrumenting code. > > http://www.cs.umd.edu/projects/dyninstAPI/ > > A small modification would make possible to change "int $80" for more > elavorate code. This has to be done when the code is loaded > (fs/binfmt_elf.c) but I think that it's feasable. I did a quick scour across their web site (and the paradyn projects site) to try to find a brief overview of how it works... but couldn't find anything. Do you know how they deal with this problem? My guess is that they take the code they are overwriting and inline it into the function that they are adding... It's interesting, but would that add too much bloat to the kernel? -Chris > > On Fri, 7 Jul 2000, Jose Renau wrote: > > > > > > > > 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. For example, a getpid could be done locally. > > > > > > This optimization could do te umlinux even faster than the "default" > > > Linux. > > > > > > Suggestions? > > > > > > On Fri, 7 Jul 2000, Chris Lattner wrote: > > > > > > > Currently, syscall entry requires the tracing thread to wake up, munge the > > > > registers around, and do other stuff before the syscall'ing thread > > > > continues in the kernel... I have two ideas to improve syscall > > > > performance: > > > > > > > > 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? > > > > 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... > > > > > > > > Does anyone see any problems with these suggestions? I may be interested > > > > in implementing them if not... > > > > > > > > -Chris > > > > > > > > > > > > > > > > _______________________________________________ > > > > User-mode-linux-devel mailing list > > > > Use...@li... > > > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel > > > > > > > > > > ------------------------------------------------------------------- > > > Jose Renau Ardevol | The great things in life are what they > > > re...@ui... | seem to be. Oscar Wilde > > > ------------------------------------------------------------------- > > > > > > > > > _______________________________________________ > > > User-mode-linux-devel mailing list > > > Use...@li... > > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel > > > > > > > ------------------------------------------------------------------- > Jose Renau Ardevol | The great things in life are what they > re...@ui... | seem to be. Oscar Wilde > ------------------------------------------------------------------- > |
|
From: Jose R. <re...@cs...> - 2000-07-07 20:25:29
|
On Fri, 7 Jul 2000, Chris Lattner wrote: > > http://www.cs.umd.edu/projects/dyninstAPI/ > > I did a quick scour across their web site (and the paradyn projects > site) to try to find a brief overview of how it works... but couldn't find > anything. Do you know how they deal with this problem? No, just now I'm compiling their code, just to play a little bit with it. I found it yesterday, and I though that maybe It was useful for the umlinux. > My guess is that they take the code they are overwriting and inline it > into the function that they are adding... > > It's interesting, but would that add too much bloat to the kernel? Maybe it's possible to have it as a external program. Some kind of preprocess program that it's executed just before the code is loaded. In this way, near all the code can be outside the kernel. I'm still thinking about it. ------------------------------------------------------------------- Jose Renau Ardevol | The great things in life are what they re...@ui... | seem to be. Oscar Wilde ------------------------------------------------------------------- |
|
From: Chris L. <sa...@sk...> - 2000-07-07 20:28:24
|
> No, just now I'm compiling their code, just to play a little bit with it. > I found it yesterday, and I though that maybe It was useful for the > umlinux. Cool... make sure to report back what you find! :) -Chris > > My guess is that they take the code they are overwriting and inline it > > into the function that they are adding... > > > > It's interesting, but would that add too much bloat to the kernel? > > Maybe it's possible to have it as a external program. Some kind of > preprocess program that it's executed just before the code is loaded. In > this way, near all the code can be outside the kernel. > > I'm still thinking about it. > > ------------------------------------------------------------------- > Jose Renau Ardevol | The great things in life are what they > re...@ui... | seem to be. Oscar Wilde > ------------------------------------------------------------------- > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X