Co to jest __kernel_vsyscall?

Question

Mam rdzeń, który wygląda bardzo różni się od tych, I zazwyczaj - większość wątków są w __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() 

Co to znaczy?

EDYCJA: W szczególności zwykle widzę wiele wątków w "pthread_cond_wait" i "___newselect_nocancel", a teraz są one w drugiej ramce w każdym wątku - dlaczego ten rdzeń jest inny?

Answer 1

__kernel_vsyscal to metoda używana przez linux-gate.so (część jądra systemu Linux) do wywoływania systemu za pomocą najszybszej dostępnej metody, najlepiej sysenter instrukcja. Rzecz jest właściwie wyjaśniona przez Johan Petersson.

Answer 2

Podczas wykonywania wywołania systemowego (np. Czytanie z pliku, rozmawianie ze sprzętem, pisanie do gniazd) w rzeczywistości tworzy się przerwanie. System następnie obsługuje przerwanie w trybie jądra, a połączenie powraca z wynikiem. W większości przypadków nie ma zbyt wiele wątków w syscall, chyba że blokujesz połączenia, w takim przypadku jest to oczekiwane.

Mówiąc dokładniej, oznacza to, że wątek czeka na wywołanie systemowe poziomu jądra. Ale to (niestety dla moich punktów) już w nazwie :)

Answer 3

Oprócz już podanego dobrego linku do wyjaśnienia, co to jest linux-gate.so, chciałbym odpowiedzieć "dlaczego ten rdzeń jest inny?". Najnowsze (nowsze niż 2.5.68) 32-bitowe systemy Linux używają strony VDSO (aka linux-gate.so.1), a wkrótce zaczną też działać systemy 64-bitowe (64-bitowy VDSO został wprowadzony w jądrze 2.6.24).

Jeśli tworzysz na starszym systemie lub ze starym glibc, to nigdy nie zobaczysz __kernel_vsyscall(), ponieważ jądro w ogóle nie stworzyło VDSO lub ponieważ (stary) glibc nie używa go nawet wtedy, gdy VDSO jest obecny.

Answer 4

Jak powiedział Adam, głównym powodem jest wydajność. Zobacz ten link dla starych numerów http://lkml.org/lkml/2002/12/9/13.

Jeśli posiadasz jądro obsługujące vDSO, nie używasz przerwań do uruchamiania syscalls, jak powiedział Stefan, w rzeczywistości było to spowodowane tym, że przerywanie działało wolniej, że cała sprawa vDSO została dodana do jądra.