Intel P6 vs P7 system call performance
Quoted 13 lines · DaveJ
Quoted 5 lines · Ville Herva
Quoted 1 line
SYSCALL is AMD. SYSENTER is Intel, and is likely to be significantly
Now that Linus has killed the dragon and everybody seems happy with the shiny new SYSENTER code, let just add one more stupid question to this
thread: has anyone made benchmarks on SYSCALL/SYSENTER/INT80 on Athlon? Is SYSCALL worth doing separately for Athlon (and perhaps Hammer/32-bit mode)?Its something I wondered about too. Even if it isn't a win for K7, it's possible that the K6 family may benefit from SYSCALL support. Maybe even the K5 if it was around that early ? (too lazy to check pdf's)
I looked at SYSCALL once, and noticed some problems:
- it doesn't even load ESP with a kernel value, a task gate for NMI is mandatory.
- SMP support is only possible with a per-cpu entry point with (boot-time) fixups to the address where the entry point can find the kernel stack.
- The AMD docs contain one odd sentence:
"The CS and SS registers must not be modified by the operating system between the execution of the SYSCALL and the corresponding SYSRET instruction". Is SYSCALL+iretd permitted? That's needed for execve, iopl, task switches, signal delivery.
What about interrupts during SYSCALLs? NMI to taskgate?
Either that sentence is just wrong, or SYSCALL is unusable.
It's not supported by the K5 cpu:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/20734.pdf
--
Manfred
Quoted 4 lines · Manfred Spraul
- The AMD docs contain one odd sentence:
"The CS and SS registers must not be modified by the operating system between the execution of the SYSCALL and the corresponding SYSRET instruction".
As I understand it is:
SYSCALL does not actually load the new CS/SS from the GDT,
but just set the internal base/limit/descriptor valid registers to "flat" values. SYSEXIT undo this. When the SYSRET is executed the selector should be still the same, otherwise the resulting state may not be exactly the same as when SYSCALL happend.
But if you make sure that CS/SS have the same state on SYSRET then everything should be ok. This means a context switch to a process with possibly different CS/SS values should be ok.
The GDT is guaranteed to stay constant and SYSCALL forbids use of an LDT for SS/CS.
I have not actually tried this on an Athlon, but on x86-64 with entering long mode it works (including context switches to processes with different segments etc.)
To add to confusion there are three different all slightly different SYSCALL flavours:
K6 (unusable iirc), Athlon/Hammer with 32bit OS
(would work, but they have SYSENTER too so it makes sense to just share code with Intel), Hammer with 64bit OS (working, has to use SYSCALL from both 32bit and 64bit processes)
They are different in what registers they clobber and how EFLAGS is handled and some other details.
On x86-64 SYSCALL is the only and native system call entry instruction for 64bit processes. The only reason to use SYSCALL from 32bit programs is that on a x86-64 SYSENTER from 32bit processes to 64bit kernels is not supported, so the 2.5.53 x86-64 kernel implements the AT_SYSINFO vsyscall page using SYSCALL.
Quoted 1 line
Is SYSCALL+iretd permitted? That's needed for execve, iopl, task
Yes, it works.
Quoted 2 lines
switches, signal delivery.
What about interrupts during SYSCALLs?
SYSCALL in 32bit mode turns off IF on entry (in long mode it is configurable using a MSR)
-Andi