C++ 什么是 __kernel_vsyscall？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/344829/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is __kernel_vsyscall?
提问by naumcho
I got a core that looks very different from the ones I usually get - most of the threads are in __kernel_vsyscall() :
我得到的内核看起来与我通常得到的内核非常不同 - 大多数线程都在 __kernel_vsyscall() 中：
9 process 11334 0xffffe410 in __kernel_vsyscall ()
8 process 11453 0xffffe410 in __kernel_vsyscall ()
7 process 11454 0xffffe410 in __kernel_vsyscall ()
6 process 11455 0xffffe410 in __kernel_vsyscall ()
5 process 11474 0xffffe410 in __kernel_vsyscall ()
4 process 11475 0xffffe410 in __kernel_vsyscall ()
3 process 11476 0xffffe410 in __kernel_vsyscall ()
2 process 11477 0xffffe410 in __kernel_vsyscall ()
1 process 11323 0x08220782 in MyClass::myfunc ()
What does that mean?
这意味着什么？
EDIT: In particular, I usually see a lot of threads in "pthread_cond_wait" and "___newselect_nocancel" and now those are on the second frame in each thread - why is this core different?
编辑：特别是，我通常在“pthread_cond_wait”和“___newselect_nocancel”中看到很多线程，现在它们位于每个线程的第二帧 - 为什么这个核心不同？
回答by coppro
__kernel_vsyscalis the method used by linux-gate.so (a part of the Linux kernel) to make a system call using the fastest available method, preferably the sysenterinstruction. The thing is properly explained by Johan Petersson.
__kernel_vsyscal是 linux-gate.so（Linux 内核的一部分）使用最快的可用方法（最好是sysenter指令）进行系统调用的方法。这件事由Johan Petersson正确解释。
回答by Stefan Mai
When you make a system call (like reading from a file, talking to hardware, writing to sockets) you're actually creating an interrupt. The system then handles the interrupt in kernel mode and your call returns with the result. Most of the time it's unusual for you to have a lot of threads in syscall unless you're making blocking calls, in which case it's expected.
当您进行系统调用（例如从文件中读取、与硬件通信、写入套接字）时，您实际上是在创建一个中断。然后系统在内核模式下处理中断，您的调用将返回结果。大多数情况下，系统调用中有很多线程是不寻常的，除非您进行阻塞调用，在这种情况下，这是意料之中的。
More specifically, it means the thread is waiting on a kernel level system call. But that's (unfortunately for my points) already in the name :)
更具体地说，这意味着线程正在等待内核级系统调用。但这（不幸的是我的观点）已经在名称中了:)
回答by Stefan Mai
In addition to the already given good link to explanation of what linux-gate.sois, I'd like to answer "why is this core different?". Most recent (newer than 2.5.68) 32-bit Linux systems use VDSO page (aka linux-gate.so.1), and 64-bit systems will soon start as well (64-bit VDSO was introduced in kernel 2.6.24).
除了已经给出的解释什么的良好链接之外linux-gate.so，我还想回答“为什么这个核心不同？”。最新的（比 2.5.68 更新）32 位 Linux 系统使用 VDSO 页（又名linux-gate.so.1），64 位系统也将很快启动（64 位 VDSO 是在内核 2.6.24 中引入的）。
If you develop on an older system, or with an old glibc, then you would never see __kernel_vsyscall(), either because the kernel didn't create VDSO at all, or because (old) glibc doesn't use it even when VDSO is present.
如果您在较旧的系统上或使用旧的 glibc 进行开发，那么您将永远不会看到__kernel_vsyscall()，因为内核根本没有创建 VDSO，或者因为（旧的）glibc 即使存在 VDSO 也不使用它。
回答by Paulo Henrique Silva
As Adam said, the main reason is performance. See this link for some old numbers http://lkml.org/lkml/2002/12/9/13.
正如亚当所说，主要原因是性能。有关一些旧数字，请参阅此链接http://lkml.org/lkml/2002/12/9/13。
If you have a vDSO enabled kernel, you're not using interrupts to run syscalls, as Stefan said, actually was because interrupts was getting slower that the whole vDSO thing was added to the kernel.
如果你有一个启用了 vDSO 的内核，你就不会使用中断来运行系统调用，正如 Stefan 所说，实际上是因为中断变得越来越慢，整个 vDSO 东西都被添加到内核中。
