Linux führt kein "opportunistisches Austauschen" im Sinne dieser Frage durch.
Die folgenden Hauptreferenzen erwähnen das Konzept überhaupt nicht:
- Linux Virtual Memory Manager verstehen. Ein Online-Buch von Mel Gorman. Geschrieben 2003, kurz vor der Veröffentlichung von Linux 2.6.0.
- Documentation/admin-guide/sysctl/vm.rst. Dies ist die primäre Dokumentation der einstellbaren Einstellungen der virtuellen Speicherverwaltung von Linux.
Genauer gesagt:
10.6 Pageout-Daemon (kswapd)
Historisch kswapd Früher wurde es alle 10 Sekunden aufgeweckt, aber jetzt wird es nur noch von der physischen Seitenzuweisung geweckt, wenn die pages_low-Anzahl freier Seiten in einer Zone erreicht ist. [...] Unter extremem Speicherdruck erledigen Prozesse die Arbeit von kswapd synchron. [...] kswapd gibt weiterhin Seiten frei, bis die Höchstgrenze von pages_high erreicht ist.
Auf der Grundlage des oben Gesagten würden wir keinen Austausch erwarten, wenn die Anzahl der freien Seiten höher als die "High Watermark" ist.
Zweitens sagt uns dies den Zweck von kswapd ist es, mehr kostenlose Seiten zu erstellen.
Wenn kswapd schreibt eine Speicherseite zum Auslagern, gibt es die Speicherseite sofort frei. kswapd behält keine Kopie der ausgetauschten Seite im Speicher .
Linux 2.6 verwendet "rmap", um die Seite freizugeben. In Linux 2.4 war die Geschichte komplexer. Wenn eine Seite von mehreren Prozessen gemeinsam genutzt wurde, konnte kswapd sie nicht sofort freigeben. Das ist alte Geschichte. Alle verlinkten Beiträge beziehen sich auf Linux 2.6 oder höher.
Austauschbarkeit
Dieses Steuerelement wird verwendet, um zu definieren, wie aggressiv der Kernel Speicherseiten austauschen wird. Höhere Werte erhöhen die Aggressivität, niedrigere Werte verringern die Swap-Menge. Ein Wert von 0 weist den Kernel an, den Austausch nicht einzuleiten, bis die Menge an freien und dateigestützten Seiten erreicht ist ist kleiner als die Hochwassermarke in einer Zone.
Dieses Zitat beschreibt einen Sonderfall:wenn Sie den swappiness konfigurieren Wert auf 0 . In diesem Fall sollten wir außerdem keinen Austausch erwarten, bis die Anzahl der Cache-Seiten auf die High Watermark gefallen ist. Mit anderen Worten, der Kernel wird versuchen, fast den gesamten Datei-Cache zu verwerfen, bevor er mit dem Auslagern beginnt. (Dies kann zu massiven Verlangsamungen führen. Sie benötigen einen Dateicache! Der Dateicache wird verwendet, um den Code aller Ihrer laufenden Programme zu speichern :-)
Was sind die Wasserzeichen?
Die obigen Zitate werfen die Frage auf:Wie groß sind die "Wasserzeichen"-Speicherreservierungen auf meinem System? Antwort:Auf einem "kleinen" System können die Wasserzeichen der Standardzone bis zu 3 % des Speichers betragen. Dies liegt an der Berechnung des "min"-Wasserzeichens. Auf größeren Systemen sind die Wasserzeichen kleiner und erreichen etwa 0,3 % des Speichers.
Wenn es also um ein System mit mehr als 10 % freiem Speicher geht, sind die genauen Details dieser Wasserzeichenlogik nicht von Bedeutung.
Die Wasserzeichen für jede einzelne "Zone" werden in /proc/zoneinfo angezeigt , wie in proc(5) dokumentiert. Ein Auszug aus meiner zoneinfo:
Node 0, zone DMA32
pages free 304988
min 7250
low 9062
high 10874
spanned 1044480
present 888973
managed 872457
protection: (0, 0, 4424, 4424, 4424)
...
Node 0, zone Normal
pages free 11977
min 9611
low 12013
high 14415
spanned 1173504
present 1173504
managed 1134236
protection: (0, 0, 0, 0, 0)
Die aktuellen "Wasserzeichen" sind min , low , und high . Wenn ein Programm jemals nach genügend Speicher fragt, um free zu reduzieren unter min , gibt das Programm "direkte Rückforderung" ein. Das Programm wartet, während der Kernel Speicher freigibt.
Eine direkte Rückforderung wollen wir nach Möglichkeit vermeiden. Wenn also free würde unter low sinken Wasserzeichen weckt der Kernel kswapd . kswapd gibt Speicher frei, indem Caches ausgetauscht und/oder gelöscht werden, bis free über high liegt wieder.
Zusatzqualifikation:kswapd wird auch ausgeführt, um den vollen lowmem_reserve-Betrag für Kernel-Lowmem- und DMA-Nutzung zu schützen. Die Standardeinstellung für lowmem_reserve beträgt etwa 1/256 der ersten 4 GiB RAM (DMA32-Zone), also normalerweise etwa 16 MiB.
Linux-Code-Commits
mm:Kswapd-Wasserzeichen proportional zum Speicher skalieren
[...]
watermark_scale_factor:
Dieser Faktor steuert die Aggressivität von kswapd. Es definiert die Menge an Speicher, die in einem Knoten/System verbleibt, bevor kswapd aufgeweckt wird, und wie viel Speicher frei sein muss, bevor kswapd wieder in den Schlafmodus wechselt.
Die Einheit ist in Bruchteilen von 10.000. Der Standardwert von 10 bedeutet, dass die Abstände zwischen Wasserzeichen 0,1 % des verfügbaren Speichers im Knoten/System betragen. Der Höchstwert ist 1000 oder 10 % des Arbeitsspeichers.
Eine hohe Rate von Threads, die direkt zurückgefordert werden (allocstall) oder kswapd vorzeitig schlafen geht (kswapd_low_wmark_hit_quickly), kann darauf hindeuten, dass die Anzahl der freien Seiten, die kswapd aus Latenzgründen verwaltet, zu klein für die im System auftretenden Zuweisungs-Bursts ist. Dieser Knopf kann dann verwendet werden, um die Aggressivität von kswapd entsprechend einzustellen.
proc:meminfo:verfügbaren Speicher konservativer schätzen
Die MemAvailable Element in /proc/meminfo soll den Benutzern einen Hinweis darauf geben, wie viel Speicher zuweisbar ist, ohne dass Auslagerungen verursacht werden, sodass die niedrigen Wasserzeichen der Zonen als für den Benutzerbereich nicht verfügbar ausgeschlossen werden.
Für eine Userspace-Zuweisung jedoch kswapd wird tatsächlich zurückgefordert, bis die freien Seiten eine Kombination aus der High Watermark und dem Low-Mem-Schutz des Seitenzuordners erreichen, der eine bestimmte Menge an DMA- und DMA32-Speicher auch vom Benutzerbereich fernhält.
Subtrahieren Sie bei der Berechnung von MemAvailable den vollen Betrag, von dem wir wissen, dass er für den Userspace nicht verfügbar ist, von der Anzahl der freien Seiten.
Linux-Code
Es wird manchmal behauptet, dass das Ändern von swappiness bis 0 wird "opportunistisches Swapping" effektiv deaktivieren. Dies bietet einen interessanten Untersuchungsweg. Wenn es etwas gibt, das "opportunistisches Swapping" genannt wird, und es kann durch Swappiness eingestellt werden, dann könnten wir es verfolgen, indem wir alle Aufrufketten finden, die vm_swappiness lesen . Beachten Sie, dass wir unseren Suchraum reduzieren können, indem wir CONFIG_MEMCG annehmen ist nicht gesetzt (d. h. "Speicher-Cgroups" sind deaktiviert). Die Aufrufkette geht:
- vm_swappiness
- mem_cgroup_swappiness
- get_scan_count
- shrink_node_memcg
- shrink_node
shrink_node_memcg wird kommentiert:"Dies ist eine grundlegende Seite, die pro Knoten freier ist. Wird sowohl von kswapd als auch von Direct Reclaim verwendet". Dh Diese Funktion erhöht die Anzahl der kostenlosen Seiten. Es wird nicht versucht, Seiten zu duplizieren, um sie auszutauschen, damit sie zu einem viel späteren Zeitpunkt freigegeben werden können. Aber selbst wenn wir das außer Acht lassen:
Die obige Kette wird von drei verschiedenen Funktionen aufgerufen, die unten gezeigt werden. Wie erwartet können wir die Call-Sites in Direct Reclaim vs. kswapd. Es wäre nicht sinnvoll, ein "opportunistisches Austauschen" in der direkten Rückforderung durchzuführen.
/* * This is the direct reclaim path, for page-allocating processes. We only * try to reclaim pages from zones which will satisfy the caller's allocation * request. * * If a zone is deemed to be full of pinned pages then just give it a light * scan then give up on it. */ static void shrink_zones
* kswapd shrinks a node of pages that are at or below the highest usable * zone that is currently unbalanced. * * Returns true if kswapd scanned at least the requested number of pages to * reclaim or if the lack of progress was due to pages under writeback. * This is used to determine if the scanning priority needs to be raised. */ static bool kswapd_shrink_node
* For kswapd, balance_pgdat() will reclaim pages across a node from zones * that are eligible for use by the caller until at least one zone is * balanced. * * Returns the order kswapd finished reclaiming at. * * kswapd scans the zones in the highmem->normal->dma direction. It skips * zones which have free_pages > high_wmark_pages(zone), but once a zone is * found to have free_pages <= high_wmark_pages(zone), any page in that zone * or lower is eligible for reclaim until at least one usable zone is * balanced. */ static int balance_pgdat
Vermutlich ist die Behauptung also, dass kswapd irgendwie aufgeweckt wird, selbst wenn alle Speicherzuweisungen sofort aus dem freien Speicher erfüllt werden. Ich habe mir die Verwendung von wake_up_interruptible(&pgdat->kswapd_wait) angesehen , und ich sehe keine Wakeups wie diese.
Nein, opportunistisches Swappen gibt es unter Linux nicht. Ich habe einige Zeit damit verbracht, mir das Problem anzusehen, und alle Quellen (Lehrbücher, E-Mails auf Mailinglisten von Kernel-Entwicklern, Linux-Quellcode und Commit-Kommentare sowie einige Twitter-Austausche mit Mel Gorman) sagen mir dasselbe:Linux fordert nur zurück Gedächtnis als Reaktion auf irgendeine Form von Gedächtnisdruck (mit der offensichtlichen Ausnahme des Winterschlafs).
Alle gängigen Missverständnisse zu diesem Thema stammen wahrscheinlich aus der einfachen Tatsache, dass Linux es sich nicht leisten kann, bis zum letzten Byte freien Speichers zu warten, bevor es mit dem Auslagern beginnt. Es braucht eine Art Polster, um es vor extremen Formen der Speichererschöpfung zu schützen, und es gibt einige einstellbare Parameter, die die Größe dieses Polsters beeinflussen können (z. B. vm.min_free_kbytes ). Aber es ist nicht dasselbe wie „tauschen, weil es nichts Besseres zu tun gibt“.
Leider ist der Seitenrahmen-Reklamationsalgorithmus im Vergleich zu 2.6 (als er ausführlich in Mel Gormans Buch beschrieben wurde) viel komplexer geworden, aber die Grundidee ist mehr oder weniger dieselbe:Die Seitenreklamation wird durch fehlgeschlagene Zuordnungen ausgelöst, die dann entweder aufwachen kswapd oder versuchen Sie, Seiten synchron freizugeben (abhängig von Speicherdruck, Zuordnungsflags und anderen Faktoren).
Der offensichtlichste Grund, warum Seitenzuweisungen mit genügend freiem Speicher fehlschlagen können, ist, dass sie möglicherweise nach zusammenhängendem Speicher fragen, während der Speicher in Wirklichkeit möglicherweise zu fragmentiert ist, um die Anforderung zu erfüllen. In der Vergangenheit haben Linux-Kernel-Entwickler große Anstrengungen unternommen, um die Notwendigkeit zusammenhängender Zuweisungen zu vermeiden. Trotzdem erfordern einige Gerätetreiber dies immer noch – entweder weil sie keine Multipage-Speicher-I/O (Scatter-Gather-DMA) ausführen können, oder es könnte einfach eine nachlässige Codierung der Treiberentwickler sein. Das Aufkommen von Transparent Huge Pages (THP) lieferte einen weiteren Grund für die Zuweisung von Speicher in physisch zusammenhängenden Blöcken.
Zone Compaction, die etwa im gleichen Zeitraum eingeführt wurde, soll bei dem Problem der Speicherfragmentierung helfen, bringt aber nicht immer den erwarteten Effekt.
Es gibt verschiedene vmscan Tracepoints, die helfen können, zu verstehen, was genau in Ihrem speziellen Fall vor sich geht -- es ist immer einfacher, das Zeug, das Sie im Linux-Kernel-Code benötigen, zu finden, wenn Sie bestimmte Call-Stacks haben, anstatt einfach alles zu scannen, das entfernt relevant erscheint.