Re: Syscall/Sysret state on i386 arch

From: Scott Long (scottl_at_samsco.org)
Date: 08/29/05

  • Next message: Dan Nelson: "Re: [PATCH] caching daemon release and nsswitch patches" 
    Date: Mon, 29 Aug 2005 10:16:32 -0600
To: John Baldwin <jhb@freebsd.org>

    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=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV
    >>,\ PAT,PSE36,MMX,FXSR,SSE>
    >> AMD Features=0xc0400800<SYSCALL,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 "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Dan Nelson: "Re: [PATCH] caching daemon release and nsswitch patches"

    Relevant Pages

    • Re: Syscall/Sysret state on i386 arch
      ... > I got a hold of the AMD document number 21086.pdf. ... > opcodes pretty well, but doesn't tell which CPUs support the new opcodes. ... Support for syscall/sysret is determined by a cpuid flag. ...
      (freebsd-hackers)
    • Re: 2.6.21-rc2-mm1
      ... no longer allowed to change the syscall number. ... We need to support a special "SET_SYSCALL" call which is passed the ...
      (Linux-Kernel)
    • Re: j#
      ... The missing IL opcodes are not documented yet but apparently two of them are: ... All our framework code and our own apps are written in C#. ... TIA, ... Visual Studio does not have the wizard and debug support for j#/compact ...
      (microsoft.public.dotnet.framework.compactframework)
    • Re: The 1n command
      ... ln is a very simply app and only links to three libraries ... kernel at a address near the top of memory during ... It contains an entry point for every syscall supported ... (Support for this with x86-64 is quite new; ...
      (uk.comp.os.linux)
    • Re: Suggestions on Avoiding syscall Overhead
      ... help on importing sysenter as syscall entry point!! ... Right now, we are forced to use INT 0x80 for syscalls, which is not very fast, even though most CPUs support SYSENTER/SYSCALL, because if we switched to these the binaries wouldn't work on older machines we still support. ... I feel that the benefits of being able to use SYSENTER when it's supported would be even greater than fast gettimeofday, for most applications on i386. ... Also, doing gettimeofday through this shared page will mostly only be useful for machines with synchronized TSCs, because otherwise you'll spend thousands of cycles just reading the HPET/ACPI timers anyway. ...
      (freebsd-current)