bfq_async_charge_factor diz que as gravações assíncronas recebem 10x menos do que o compartilhamento “justo” da taxa de transferência do dispositivo. Como posso observar isso?

Question

Eu tenho lido sobre o CONFIG_WBT e também o BFQ. Eu tentei comparar o WBT v.s. CFQ no meu disco rígido. Eu aprendi que o CFQ tenta controlar o massivo write-up assíncrono do Linux, mas seu sucesso é limitado por causa do cache de write-back do disco rígido. Desativar o cache de gravação de hardware (mas deixando o NCQ ativado) no meu disco permitiu um controle muito melhor. [1]

[1] Determine o benefício específico da limitação de write-back (CONFIG_WBT)

Eu sei que o WBT está atualmente desativado no CFQ / BFQ. Além disso, uma vez que o upstream do Linux v4.19 está empurrando o blk-mq como um padrão para o scsi, as distribuições, e. O Fedora precisa alternar de CFQ para BFQ por padrão, ou voltar para a camada de bloco "legado", ou etc., de acordo com suas avaliações. Então, eu gostaria de entender o BFQ.

Eu li o BFQ tem duas heurísticas do lado do hardware. Ele "sobrecarga" escreve por 10x, para atenuar o efeito do cache de gravação do dispositivo. Ele também tenta atenuar o efeito do NCQ usando inativo. Por enquanto, estou mais confuso com a sobrecarga de gravação.

To keep low the ratio between the number of write requests and the number of read requests served, we just added a write (over)charge coefficient: for each sector written, the budget of the active application is decremented by this coefficient instead of one. As shown by our experimental results, a coefficient equal to ten proved effective in guaranteeing high throughput and low latency.

http://algo.ing.unimo.it/people/paolo/disk_sched/bf1-v1-suite-results.pdf

/*
 * Async to sync throughput distribution is controlled as follows:
 * when an async request is served, the entity is charged the number
 * of sectors of the request, multiplied by the factor below
 */
static const int bfq_async_charge_factor = 10;

link

(Eu não vejo nenhum código no BFQ para desabilitar esse fator quando o cache de write-back está desabilitado. Eu vejo o WBT incluído algum código para rastrear se o cache writeback está habilitado, por razões muito similares. Em princípio eu assumo que o BFQ poderia fazer o mesma coisa, mas agora parece que o BFQ irá sempre sobrecarregar as gravações, mesmo que o BFQ apenas afirme que é necessário em dispositivos com cache de write-back).

Isso diz que as gravações assíncronas receberão uma parcela muito menor da taxa de transferência do dispositivo. Existe um caso de teste simples para observar esse compartilhamento "injusto"? Ou eu estou entendendo mal?

Meu link acima incluiu um teste rápido de BFQ. Esta foi uma leitura simultânea v.s. escrever com configurações padrão fio . Acho que o BFQ deu ao leitor e ao escritor algo muito mais próximo de uma participação "justa". (O leitor conseguiu 40MB / s no meu disco rígido).