Opravdu se snažím pochopit, proč naše hostující virtuální počítače nepoužívají ovladač kvm-clock „jak by měly“. Používají RHEL 7.2, glibc-2.17, Kern 3.10.0. Programy jako date a perl -e 'print time' získat aktuální čas, ale udělejte to bez systémového volání. To je potvrzeno pomocí strace a ltrace a dále potvrzeno použitím gdb a trasováním přes sestavení, které obešlo syscall a místo toho provedl nějakou instrukci nazvanou rtdscp .
Je to pokus o optimalizaci autorů glibc? Existuje nějaký způsob, jak to zakázat a vynutit volání glibc, aby provedla systémové volání (krátké LD_PRELOAD hacky)?
AKTUALIZACE 2016-10-14:
Po přezkoumání posledního návrhu POSIX je část odpovědi jasná:existuje způsob, jak vyžádat hodiny od CPU, ale GNU glibc neprávem vnutila tuto implementaci svým uživatelům. Řešením je vyvolat systémové volání přímo. (Booooh)
Pokud je definován _POSIX_CPUTIME, implementace musí podporovat hodnoty ID hodin získané vyvoláním clock_getcpuclockid(), které představují hodiny CPU daného procesu. Implementace budou také podporovat speciální hodnotu clockid_t CLOCK_PROCESS_CPUTIME_ID, která představuje hodiny CPU volajícího procesu při vyvolání jednoho z hodin_() nebo timer_ () funkce.
Vzhledem k tomu, že uživatel může Existuje nějaký skutečný argument proti názoru, že pokud clock_id je nastaven na CLOCK_REALTIME , má být použito systémové volání?
Přijatá odpověď:
Domnívám se, že důvodem, proč nevidíte, že se syscall děje, je to, že některá systémová volání Linuxu (zejména ta související s časem, jako gettimeofday(2) a time(2) ) mají speciální implementace prostřednictvím vDSO, které obsahuje poněkud optimalizované implementace některých systémových volání:
„vDSO“ (virtuální dynamický sdílený objekt) je malá sdílená knihovna
, kterou jádro automaticky mapuje do adresního prostoru všech
aplikací v uživatelském prostoru.Existují některá systémová volání
jádro zajišťuje, že kód v uživatelském prostoru skončí často, a to až do
bodu, že taková volání mohou dominovat celkovému výkonu. To je způsobeno
jak frekvencí volání, tak i režií přepínání kontextu
, která je důsledkem opuštění uživatelského prostoru a vstupu do
jádra.
Nyní se v příručce zmiňuje, že požadované informace jsou pouze umístěny v paměti, aby k nim měl proces přímý přístup (aktuální čas nakonec není příliš tajný). Nevím o přesné implementaci a mohl jsem jen hádat o roli počítadla časové značky CPU v it.
Takže optimalizaci ve skutečnosti neprovádí glibc, ale jádro. Lze jej deaktivovat nastavením vdso=0 na příkazovém řádku jádra a mělo by být možné jej zkompilovat. Nemohu však zjistit, zda je možné jej zakázat na straně glibc (alespoň bez záplatování knihovny).
Existuje spousta dalších informací a zdrojů k této otázce na SE.
V otázce jste řekli:
Po přezkoumání posledního návrhu POSIX je část odpovědi jasná:existuje způsob, jak vyžádat hodiny od CPU, ale GNU glibc neprávem vnutila tuto implementaci svým uživatelům.
Což si myslím, že je dost odvážné tvrzení. Nevidím žádné důkazy o tom, že by se uživatelům něco „nesprávně vnucovalo“, alespoň ne v jejich neprospěch. Implementaci vDSO používá téměř každý linuxový proces běžící na současných systémech, což znamená, že pokud by nefungoval správně, byly by již vyslyšeny velmi hlasité stížnosti. Také jste sami řekli, že obdržený čas je správný.
Citát, který zadáte z clock_gettime zdá se, že manuál pouze uvádí, že volání musí podporovat ID hodin vrácené clock_getcpuclockid , nic o chování CLOCK_REALTIME nebo gettimeofday .