On Thursday 11 April 2013 14:31:55 Andy Lutomirski wrote: > On Tue, Apr 9, 2013 at 8:17 PM, Mike Frysinger <vapier@xxxxxxxxxx> wrote: > > so i've slapped this together. i think the HISTORY section could use > > more filling out, but that'd probably be more for funsies rather than > > usefulness. > > This looks good to me. It may be worth mentioning that programs must > not assume anything about where the vDSO is mapped -- that may change > from kernel to kernel or exec to exec, unless the particular > architecture makes some guarantee. good idea > > .SS Example Background > > Making syscalls themselves can incur significant penalty. > > In x86 systems, you can trigger a software interrupt (int $0x80) to tell > > the kernel you wish to make a syscall. > > Internally, this means the call has to go through the normal interrupt > > layers to save/restore context before it even gets a chance to start > > processing the system call. > > Wouldn't it be nicer if you could start processing the system call > > immediately? With newer revisions of the x86 architecture, there is now > > a syscall/sysenter instruction that does exactly that (jumps directly to > > the system call entry). However, rather than require the C library to > > figure out if this functionality is available itself, the vDSO includes > > symbols that can be used. This is typically referred to using the term > > "vsyscall". > > I find this a bit confusing. The term "vsyscall" means something > different on x86_64, and syscall and sysenter are different > instructions. How about this: > > Making syscalls can be slow. > In x86 32-bit systems, you can trigger a software interrupt (int > $0x80) to tell the > kernel you wish to make a syscall. This instruction is expensive: it > goes through the full interrupt handling paths in microcode and in the > kernel. Newer processors have faster, incompatible ways to issue > system calls, and the kernel abstracts these through an entry point in > the vdso. (The terminology can be confusing. On x86_32, this > function is called __kernel_vsyscall, but on x86_64, the term > "vsyscall" refers to an obsolete way to ask the kernel what time it is > or what cpu the caller is on.) i've merged in your suggestions. is the current (small) HISTORY section correct then ? you can find it at the bottom of the page. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
