ion@svn.reactos.com wrote:
SYSENTER support, INT2E Optimization, new Syscall Table/Stub generator and svn:ignore fixes. Please read associated Mailing List Post.
Added files: trunk/reactos/tools/nci/ trunk/reactos/tools/nci/makefile trunk/reactos/tools/nci/ncitool.c trunk/reactos/tools/nci/sysfuncs.lst trunk/reactos/tools/nci/w32ksvc.db
Updated files: trunk/reactos/Makefile trunk/reactos/config trunk/reactos/include/napi/shared_data.h trunk/reactos/ntoskrnl/Makefile trunk/reactos/ntoskrnl/include/internal/i386/ke.h trunk/reactos/ntoskrnl/include/internal/i386/ps.h trunk/reactos/ntoskrnl/ke/i386/bthread.S trunk/reactos/ntoskrnl/ke/i386/exp.c trunk/reactos/ntoskrnl/ke/i386/gdt.c trunk/reactos/ntoskrnl/ke/i386/kernel.c trunk/reactos/ntoskrnl/ke/i386/stkswitch.S trunk/reactos/ntoskrnl/ke/i386/syscall.S trunk/reactos/ntoskrnl/ke/i386/usercall.c trunk/reactos/ntoskrnl/ke/kthread.c trunk/reactos/ntoskrnl/ke/process.c trunk/reactos/ntoskrnl/ps/i386/continue.c trunk/reactos/subsys/system/vmwinst/vmwinst.c
Deleted files: trunk/reactos/iface/
First and foremost, I would really like to thank all the people behind the scenes of this patch; Filip Navara, for the initial implementation and thoughts, and his consistent help, Art Yerkes for his invaluable testing, and everyone else who lent a hand (too many people to list here).
This patch improves by around 15-20% (tested but not scientific) the speed of ReactOS on all hardware and virtual machines. Furthermore, it improves speed by over 50% (tested but not scientific) on hardware supporting the SYSENTER/SYSEXIT call pair. On VMWare however, due to causes still under investigation, SYSENTER/SYSEXIT must be disabled, or else there is a 3X slowdown. Vmwinst takes care of writing the Windows-compatible Value in the Registry, and it is read before choosing which kind of call to execute. This means that vmware is able to take advantage of the ~20% speedup, but not of all the full capability of this patch.
It also combines the previous iface tools into a single, much more dynamic and small utility, which I called NCITool (Native Call Interface Tool). Although it is almost final, I still have to set-up the macros for portability and msvc compatibility, so this is a known issue (note however that the previous version suffered from the same incompatibilies). I will fix it during the week. I would like to thank Emanuelle and KJK::Hyperion for the original tool, and most of the parsing code has remained intact, apart from some code-duplication removal and simplification.
The following two issues remain in this patch, which I will look at this week as well:
1) SMP. I have not tested SYSENTER on an SMP machine, and I believe that the MSRs must be written on other CPUs as well, perhaps using an IPI? 2) Pentium Pro. It erronously reports the SEP flag but does not support SYSENTER. Code must be added at the related FIXME in order to check for this.
I have, along with others, tested this patch for more then a week now, and I have found no visible problems, apart from the VMWare weirdness. If any problems are noticed due to it, please post accordingly and I will have a look at it.
Best regards, Alex Ionescu
Well done!
Regards Jason
On Mon, 17 Jan 2005 02:21:49 -0500, Alex Ionescu ionucu@videotron.ca wrote:
ion@svn.reactos.com wrote: First and foremost, I would really like to thank all the people behind the scenes of this patch; Filip Navara, for the initial implementation and thoughts, and his consistent help, Art Yerkes for his invaluable testing, and everyone else who lent a hand (too many people to list here).
This patch improves by around 15-20% (tested but not scientific) the speed of ReactOS on all hardware and virtual machines. Furthermore, it improves speed by over 50% (tested but not scientific) on hardware supporting the SYSENTER/SYSEXIT call pair.
From: Alex Ionescu
Well, I have good news and I have bad news. Let's start with the good news
This patch improves by around 15-20% (tested but not scientific) the speed of ReactOS on all hardware and virtual machines. Furthermore, it improves speed by over 50% (tested but not scientific) on hardware supporting the SYSENTER/SYSEXIT call pair.
I have done some testing using rosperf (reactos/apps/utils/rosperf) and for some of the tests (making lots of calls into the kernel) I see a significant improvement (larger number is better):
Small Fill, old 32400/s, new 36600/s, improvement 13% Horizontal Lines, old 23900/s, new 28800/s, improvement 20.5% Vertical Lines, old 15100/s, new 16800/s, improvement 11.3% Lines, old 7930/s, new 8430/s, improvement 6.3% Fill, old 126/s, new 126/s, unchanged
We're now beating the XP VgaSave (default non-hardware accelerated driver, comparable to our VBE driver) for some tests: XP smallfill 32500/s, hlines 19900/s, vlines 20200/s, lines 19700/s, fill 126/s These tests were done on a 300MHz Celeron machine.
On VMWare however, due to causes still under investigation, SYSENTER/SYSEXIT must be disabled, or else there is a 3X slowdown. Vmwinst takes care of writing the Windows-compatible Value in the Registry, and it is read before choosing which kind of call to execute. This means that vmware is able to take advantage of the ~20% speedup, but not of all the full capability of this patch.
This is where the bad news starts. Using an older version of VMware (4.0.5 build-6030 to be exact) ReactOS causes VMware to crash soon after smss.exe is loaded, so my guess is that this happens on the first SYSENTER. This is bad 'cause it also happens during setup, before vmwinst has run. Another problem: it seems we're not allowed to do floating point arithmetic in usermode anymore. On the first floating point operation the process is terminated with a page fault exception.
Congratulations to Alex and the other people who made this happen, I think this is a significant step forward in performance.
Gé van Geldorp.