Perché il driver UART 8250 non riattiva TTY se sono in sospeso più di 256 caratteri?

Qual è la motivazione di questa if-condition void serial8250_tx_chars(struct uart_8250_port *up)?

if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
    uart_write_wakeup(port);

È stato lì sin da Linux 1.1.13 (maggio 1994) e si ripete nella maggior parte dei driver UART.

Sfondo: Linux 3.4.91 personalizzato, sistema incorporato su ARMv7, porta UART 0 configurata per 38400 baud, FIFO 16 byte per I / O. Niente di tutto ciò può essere modificato nella nostra configurazione.

Quando si stampa molto pesantemente sulla console tramite UART, il buffer interno da 4kB ( UART_XMIT_SIZE) si riempie e quindi blocca il processo di spazio utente fino allo svuotamento del buffer (che richiede un secondo a 38400 baud!). Quindi questo comportamento si ripete. Questo perché la funzione n_tty_write()va in sospensione quando il buffer è pieno e non viene svegliata a lungo a causa della condizione discutibile sopra.

Lo troverei più naturale ed efficiente se questo controllo fosse semplicemente rimosso. Quindi i printfs riempirebbero il buffer il più rapidamente possibile, e quindi continuerebbero alla velocità con cui il buffer viene svuotato , piuttosto che l'elaborazione a raffica che sto osservando.

Funziona bene nel mio ambiente ma sicuramente mi manca o fraintendo qualcosa. Ci deve essere un motivo per l'attuale implementazione. Ci sono effetti collaterali se rimuovo quella condizione?

Come domanda secondaria: ci sono opzioni di configurazione per ottimizzare questo comportamento, ad esempio per fare in modo che printf ritorni sempre immediatamente e scarti l'output se il buffer è pieno?

È una misura di efficienza. La CPU funziona molto più velocemente della porta seriale che se il kernel lascia funzionare il processo userspace ogni volta che c'è un po 'di spazio nel buffer, finirebbe per fare un viaggio nello spazio utenti e tornare indietro per ogni singolo byte di dati. È molto dispendioso in termini di tempo della CPU:

$ time dd if=/dev/zero of=/dev/null bs=1 count=10000000
10000000+0 records in
10000000+0 records out
10000000 bytes (10 MB, 9.5 MiB) copied, 5.95145 s, 1.7 MB/s

real    0m5.954s
user    0m1.960s
sys     0m3.992s

$ time dd if=/dev/zero of=/dev/null bs=1000 count=10000
10000+0 records in
10000+0 records out
10000000 bytes (10 MB, 9.5 MiB) copied, 0.011041 s, 906 MB/s

real    0m0.014s
user    0m0.000s
sys     0m0.012s

Il test di cui sopra non è nemmeno leggere e scrivere un dispositivo reale: la differenza di tempo è la frequenza con cui il sistema rimbalza tra spazio utente e spazio kernel.

Se userspace non vuole essere trattenuto, può usare l'I / O non bloccante, oppure può controllare usa una select()chiamata per vedere se c'è spazio per scrivere sul dispositivo ... e se non lo è, può scaricare il resto in un buffer a sé stante e continua l'elaborazione. Certo, questo complica le cose, dal momento che ora hai un buffer che devi svuotare ... ma se stai usando stdio, questo è generalmente vero comunque.