Re: Syscall/Sysret state on i386 arch
On Sunday 28 August 2005 10:32 am, alexander wrote: The AMD64 arch is using the syscall/sysret opcodes instead of int80h to perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the output my of dmesg and it says: CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x671 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV ,\ PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow I got a hold of the AMD document number 21086.pdf. It describes both opcodes pretty well, but doesn't tell which CPUs support the new opcodes. But since the first revision of that document is dated Sept 1997 quite a lot of i386 CPU's should support the opcodes. The NASM manual only states [P6,AMD] as the required CPU to perform those opcodes. I found some patches for Linux that replace the int80h syscall calling convention with syscall/sysret on i386 and the results look pretty convincing: (INT $0x80 based getpid(), got pid 497) latency:282 cycles (SYSENTER based getpid(), got pid 497) latency:138 cycles on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html Does anybody know more about this? Is it even possible to replace the current syscall implementation that easily or would that require elaborate changes to all the syscalls (libc), etc. And which CPU's support these new opcodes? Doesn anybody know if the Linux patches actually got comitted to the official kernel? Support for syscall/sysret is determined by a cpuid flag. I do believe someone has worked on either syscall/sysret or sysenter/sysexit support in a p4 branch. You can try asking jeff@ about it. I think it was sysenter/sysexit and it didn't really improve things much. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syscall/Sysret state on i386 arch
John Baldwin wrote: On Sunday 28 August 2005 10:32 am, alexander wrote: The AMD64 arch is using the syscall/sysret opcodes instead of int80h to perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the output my of dmesg and it says: CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x671 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV ,\ PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow I got a hold of the AMD document number 21086.pdf. It describes both opcodes pretty well, but doesn't tell which CPUs support the new opcodes. But since the first revision of that document is dated Sept 1997 quite a lot of i386 CPU's should support the opcodes. The NASM manual only states [P6,AMD] as the required CPU to perform those opcodes. I found some patches for Linux that replace the int80h syscall calling convention with syscall/sysret on i386 and the results look pretty convincing: (INT $0x80 based getpid(), got pid 497) latency:282 cycles (SYSENTER based getpid(), got pid 497) latency:138 cycles on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html Does anybody know more about this? Is it even possible to replace the current syscall implementation that easily or would that require elaborate changes to all the syscalls (libc), etc. And which CPU's support these new opcodes? Doesn anybody know if the Linux patches actually got comitted to the official kernel? Support for syscall/sysret is determined by a cpuid flag. I do believe someone has worked on either syscall/sysret or sysenter/sysexit support in a p4 branch. You can try asking jeff@ about it. I think it was sysenter/sysexit and it didn't really improve things much. Actually, the results were fairly inconclusive because it was also somewhat unstable under real loads. The work is in Perforce under //depot/user/jeff/sysenter/... I've worked on this branch also, but not in a few months. I can make patches if anyone is interested. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syscall/Sysret state on i386 arch
On Mon Aug 29 05, Scott Long wrote: Actually, the results were fairly inconclusive because it was also somewhat unstable under real loads. The work is in Perforce under //depot/user/jeff/sysenter/... I've worked on this branch also, but not in a few months. I can make patches if anyone is interested. Scott That would be awsome. I'd defenately check it out, because I'm really interested to see how syscall/sysret compares to the current way of doing syscalls. Maybe somebody can comment on the speed increase that was gained by replacing int80h in the AMD64 branch. I just had a look at lib/libc/amd64/SYS.h and it seems they decided to use syscall/sysret instead of int80h about 2 years ago: Revision 1.25 (Wed Apr 30 18:06:14 2003 UTC (2 years, 4 months ago) by peter) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Syscall/Sysret state on i386 arch
The AMD64 arch is using the syscall/sysret opcodes instead of int80h to perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the output my of dmesg and it says: CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x671 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,\ PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow I got a hold of the AMD document number 21086.pdf. It describes both opcodes pretty well, but doesn't tell which CPUs support the new opcodes. But since the first revision of that document is dated Sept 1997 quite a lot of i386 CPU's should support the opcodes. The NASM manual only states [P6,AMD] as the required CPU to perform those opcodes. I found some patches for Linux that replace the int80h syscall calling convention with syscall/sysret on i386 and the results look pretty convincing: (INT $0x80 based getpid(), got pid 497) latency:282 cycles (SYSENTER based getpid(), got pid 497) latency:138 cycles on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html Does anybody know more about this? Is it even possible to replace the current syscall implementation that easily or would that require elaborate changes to all the syscalls (libc), etc. And which CPU's support these new opcodes? Doesn anybody know if the Linux patches actually got comitted to the official kernel? Cheers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
