[LINUX] Treten Sie ein in die Dunkelheit von msync

Diese Zusammenfassung

--msync (MS_ASYNC) macht nichts (unverständlich)

Treten Sie ein in die Dunkelheit von msync

https://www.oreilly.co.jp/community/blog/2010/09/buffer-cache-and-aio-part2.html

In diesem Fall gibt msync (2) an, dass der Speicherbereich auf die Festplatte zurückgeschrieben werden muss. Wenn Sie MS_ASYNC angeben, wird der Systemaufruf nur durch Benachrichtigung beendet. Wenn MS_SYNC angegeben ist, wird zusätzlich zur Benachrichtigung die Verarbeitung entsprechend fsync (2) intern ausgeführt und die Daten werden auf die Festplatte zurückgeschrieben.

Ich werde den Quellcode hier lesen.

Linux Kernel Kommentare

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/msync.c

/*

• MS_SYNC syncs the entire file - including mappings.
• MS_ASYNC does not start I/O (it used to, up to 2.5.67).
• Nor does it marks the relevant pages dirty (it used to up to 2.6.17).
• Now it doesn't do anything, since dirty pages are properly tracked.
• The application may now run fsync() to
• write out the dirty pages and wait on the writeout and check the result.
• Or the application may run fadvise(FADV_DONTNEED) against the fd to start
• async writeout immediately.
• So by not starting I/O in MS_ASYNC we provide complete flexibility to
• applications. */

MS_SYNC synchronisiert alle Dateien einschließlich der Zuordnung. MS_ASYNC startet keine E / A (wurde vor 2.5.67 verwendet). Außerdem wird es nicht in Verbindung mit schmutzigen Seiten markiert (es wurde vor 2.6.17 markiert). Zu diesem Zeitpunkt werden schmutzige Seiten ordnungsgemäß nachverfolgt, sodass ich momentan nichts unternehme.

Die Anwendung schreibt fehlerhafte Seiten, sodass Sie fsync () ausführen können, um zu überprüfen, wann das Schreiben abgeschlossen ist oder welches Ergebnis erzielt wurde. Alternativ kann die Anwendung fadvise (FADV_DONTNEED) für den sofortigen asynchronen Export ausführen. Daher kann in MS_ASYNC der Anwendung vollständige Flexibilität bereitgestellt werden, indem keine E / A initiiert wird.

Schauen Sie sich den tatsächlichen Quellcode an

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/msync.c#n61

Wenn Sie nur die wichtigen Teile extrahieren,

	/*
	 * If the interval [start,end) covers some unmapped address ranges,
	 * just ignore them, but return -ENOMEM at the end.
	 */
	down_read(&mm->mmap_sem);
	vma = find_vma(mm, start);
	for (;;) {

<Ausgelassen>

		start = vma->vm_end;
		if ((flags & MS_SYNC) && file &&
				(vma->vm_flags & VM_SHARED)) {
			get_file(file);
			up_read(&mm->mmap_sem);
			error = vfs_fsync_range(file, fstart, fend, 1);
			fput(file);
			if (error || start >= end)
				goto out;
			down_read(&mm->mmap_sem);
			vma = find_vma(mm, start);
		} else {
			if (start >= end) {
				error = 0;
				goto out_unlock;
			}
			vma = vma->vm_next;
		}
	}

Wenn also MS_SYNC angegeben ist und eine Zuordnung möglich ist, wird dies von vfs_fsync_range () und fput (Datei) wiedergegeben. Wenn nicht, tut er wirklich nichts.

Wenn Sie dann MS_ASYNC angeben, wann wird dies wiedergegeben? Wird als schmutzige Seite behandelt und standardmäßig alle 5 Sekunden von pdflush () aktualisiert.

https://naoya-2.hatenadiary.org/entry/20070523/1179938637

Dieser Patch wurde gereinigt

Anscheinend kann die Behandlung des schmutzigen Status jetzt automatisiert werden, so dass es den Anschein hat, als sei er überarbeitet worden, einschließlich der Tatsache, dass es verschwenderisch war, das Flag zu setzen. Ich sehe ich sehe.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/mm/msync.c?id=204ec841fbea3e5138168edbc3a76d46747cc987

[PATCH] mm: msync() cleanup With the tracking of dirty pages properly done now, msync doesn't need to scan the PTEs anymore to determine the dirty status.

From: Hugh Dickins <hugh＠veritas.com>

In looking to do that, I made some other tidyups: can remove several #includes, and sys_msync loop termination not quite right.

Most of those points are criticisms of the existing sys_msync, not of your patch.
In particular, the loop termination errors were introduced in 2.6.17: I did notice this shortly before it came out, but decided I was more likely to get it wrong myself, and make matters worse if I tried to rush a last-minute fix in. And it's not terribly likely to go wrong, nor disastrous if it does go wrong (may miss reporting an unmapped area; may also fsync file of a following vma).

Die Verfolgung schmutziger Seiten ist jetzt besser, und msync muss den PTE nicht mehr scannen, um den Status schmutziger Seiten zu ermitteln.

From: Hugh Dickins <hugh＠veritas.com>

Zu diesem Zweck habe ich einige Aufräumarbeiten durchgeführt, z. B. das Entfernen unnötiger Inludes. Und die Schleifenbeendigungsbedingung von sys_nsync war falsch.

Die meisten dieser Punkte verweisen auf vorhandenes sys_msync, nicht auf Ihren Patch. Insbesondere wurden in 2.6.17 Schleifenbeendigungsfehler eingeführt. Ich bemerkte dieses Problem kurz bevor es passierte, aber es war wahrscheinlicher, dass ich selbst einen Fehler machte, und eine Korrektur in letzter Minute machte es noch schlimmer. Es hat nicht funktioniert (möglicherweise verpassen Sie Berichte über nicht zugeordnete Bereiche, und Sie haben möglicherweise auch die folgende vma fsync-Datei).