Y a-t-il une vitesse de niveau du système d'exploitation (Linux) lors de l'écriture d'un tampon fixe d'octet sur de nombreux descripteurs de fichiers? Lorsque vous écrivez de nombreux tampons à un descripteur de fichiers, on peut utiliser writev (2) code>, alors je me demande s'il y a un analogue à cela ou si elle doit être effectuée par plusieurs appels sys-sys. P>
3 Réponses :
Je ne connais pas de type SysCall sur Linux. Leur liste exhaustive est donnée dans le syscalls (2) man 'Page. P>
Et je ne vous dérangerai pas beaucoup. Pour l'accès au fichier, le véritable goulot d'étranglement est le disque ... p>
Sauf que cela écrit ne pas aller sur le disque; Tous les écriture code> copient les données sur un tampon dans le noyau. (Il existe des options pour changer cela, mais c'est le comportement par défaut.) Et la question de l'OP est une bonne, car s'il y avait une telle question, cela signifierait une copie et probablement un seul tampon dans le noyau (moins de ressources utilisé dans le noyau).
Je suis d'accord et je sais que, mais lorsque vous avez suffisamment de RAM afin que tous les fichiers chauds soient adaptés à l'intérieur, vous ne devriez pas vous inquiéter. Je ne pense pas que le noyau puisse partager des segments de fichiers entre fichiers distincts.
@Jameskanze: Je ne suis pas sûr que le tampon partagé fonctionnerait. Si vous avez deux fichiers, un sur un disque SSD et un sur un réseau de réseau bien éloigné, si le SSD attend le lecteur réseau? Selon la situation, vous préférerez peut-être avoir au moins un fichier écrit avec succès plutôt que deux demi-écrivies.
Une combinaison de vmsplice code> et
TEE code> devrait faire ce qui a été demandé, ce sont de multiples appels de ceux-ci, mais la barrière de l'espace utilisateur / du noyau est croisée une seule fois. p>
Merci, mais ce n'est que pour les pipes.
Je ne l'ai pas utilisé mais cela pourrait fonctionner: LIO_LISTIO P>