Ce résumé

--msync (MS_ASYNC) ne fait rien (inintelligible)

Entrez dans l'obscurité de msync

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

Dans ce cas, c'est msync (2) qui vous indique que la zone mémoire doit être réécrite sur le disque. Si vous spécifiez MS_ASYNC, l'appel système se termine simplement par une notification. Si MS_SYNC est spécifié, en plus de la notification, un traitement équivalent à fsync (2) est effectué en interne et les données sont réécrites sur le disque.

Je vais lire le code source ici.

Commentaires du noyau Linux

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 synchronise tous les fichiers, y compris le mappage. MS_ASYNC ne démarre pas les E / S (il était utilisé avant 2.5.67). De plus, il ne marque pas en association avec des pages sales (il était marqué avant le 2.6.17). À ce stade, les pages sales sont correctement suivies, donc je ne fais rien pour le moment.

L'application écrit des pages sales, vous pouvez donc exécuter fsync () pour vérifier quand l'écriture est terminée ou le résultat. Sinon, l'application peut exécuter fadvise (FADV_DONTNEED) pour une exportation asynchrone immédiate. Par conséquent, dans MS_ASYNC, une flexibilité totale peut être fournie à l'application en ne lançant pas les E / S.

Jetez un œil au code source réel

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

Si vous n'extrayez que les parties importantes,

	/*
	 * 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 (;;) {

<Omis>

		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;
		}
	}

Ainsi, si MS_SYNC est spécifié et que le mappage est possible, il sera reflété par vfs_fsync_range () et fput (fichier). Sinon, il ne fait vraiment rien.

Ensuite, si vous spécifiez MS_ASYNC, quand sera-t-il reflété? Est traitée comme une page sale et est mise à jour toutes les 5 secondes par défaut par pdflush ().

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

Ce patch a été nettoyé

Apparemment, le traitement du statut sale peut maintenant être automatisé, il semble donc qu'il a été remanié, y compris le fait qu'il était inutile de définir le drapeau. Je vois je vois.

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).

Le suivi des pages sales est désormais meilleur et msync n'a plus besoin d'analyser le PTE pour déterminer l'état des pages sales.

From: Hugh Dickins <hugh＠veritas.com>

Pour ce faire, j'ai fait un nettoyage, comme la suppression des intrants inutiles. Et la condition de terminaison de boucle de sys_nsync était incorrecte.

La plupart de ces points pointent vers sys_msync existant, pas vers votre patch. En particulier, des erreurs de terminaison de boucle ont été introduites dans 2.6.17. J'ai remarqué ce problème peu de temps avant qu'il ne se produise, mais j'étais plus susceptible de faire une erreur moi-même, et une solution de dernière minute l'a encore aggravé. Cela n'a pas fonctionné (vous pouvez manquer des rapports de zones non mappées, et vous pouvez également avoir le fichier vma fsync suivant).