Por que as leituras de / dev / zero não contam como IO_RBYTES?
Estou esvaziando um disco rígido em alguns sistemas operacionais Linux 4.x usando este comando:
E eu abri outro tty e comecei sudo htope notei isso:
O valor de IO_WBYTESparece bastante normal, mas IO_RBYTESpermanece em 4 KiB e nunca muda.
Eu corri alguns outros programas, por exemplo
e ficou surpreso ao ver que nenhum deles gera muito IO_RBYTESou IO_WBYTES.
Eu acho que isso não é específico para nenhum programa, mas por que não lê /dev/zeroe grava para /dev/{zero,null}contar como bytes de E / S?
Estou curioso, por que você acha que eles devem contar como E / S?
— marcelm 20/02
@marcelm Acho que qualquer entrada / saída deve contar como E / S, incluindo arquivo R / W, E / S de rede e muito mais.
— iBug 21/02
mas essas operações executam E / S no hardware (disco e placa de rede, respectivamente) e precisam passar por algum barramento de E / S (como o PCI-express), o que pode ser um gargalo significativo. As gravações para, por exemplo, /dev/nullnão terminam a interface com esse hardware e não obstruem os barramentos de E / S. Levado ao extremo; As leituras / gravações na / da memória também são de E / S? Obviamente, não há delineamento rígido para essas coisas, e tudo depende de qual perspectiva você adota e de quão útil essa perspectiva acaba sendo para você.
— marcelm 21/02
Observe que meu primeiro comentário pretendia provocar você (e outros) a pensar nessas perspectivas e descobrir por que você está adotando sua perspectiva. Não pretendo insinuar que você está errado; Eu nem acho que a situação é tão preto e branca. Mas, pessoalmente, eu estaria muito mais interessado em estatísticas de E / S em hardware real (que pode muito bem ser um gargalo) do que em /dev/{null,zero}(que geralmente não é um gargalo). Essa é apenas a minha perspectiva:)
— marcelm em 21/02
@marcelm Mas eu estava inicialmente pensando que qualquer read(2)e write(2)conta como I / O, que é muito razoável em seu próprio sentido.
Eles contam como E / S, mas não do tipo medido pelos campos que você está vendo.
Em htop, IO_RBYTESe IO_WBYTESmostre os campos read_bytese write_bytesde /proc/<pid>/io, e esses campos medem os bytes que passam pela camada de blocos. /dev/zeronão envolve a camada de bloco; portanto, as leituras dela não aparecem lá.
Para ver as E / S de /dev/zero, você precisa olhar para os campos rchare , que aparecem como e :wchar/proc/<pid>/iohtopRCHARWCHAR
rchar : caracteres lidos
O número de bytes que esta tarefa causou para ser lida no armazenamento. Esta é simplesmente a soma de bytes para os quais esse processo passou read(2)e chamadas similares do sistema. Ele inclui itens como E / S terminal e não é afetado pela necessidade de E / S de disco físico real (a leitura pode ter sido satisfeita no pagecache).
wchar : caracteres escritos
O número de bytes que essa tarefa causou ou deve causar a gravação no disco. Advertências semelhantes se aplicam aqui como no rchar.
Veja man 5 proce man 1 htoppara detalhes.
Então é rchare wcharisso conta bytes de chamadas para read(2)e write(2), certo?
Fale sobre frases enganosas na descrição de rchar . Tudo o que passou read()definitivamente não é "lido do armazenamento "!
— ilkkachu 20/02
@ilkkachu, storageeles significam "qualquer linha de barramento concebível", independentemente de o armazenamento em questão ser físico ou virtual ou mmap'd ou um soquete virtual ou no cache L1 - é apenas algo fora da memória mapeada desse programa, incluindo compartilhada