Announcement

Collapse
No announcement yet.

The NULL TTY Driver Makes It Into The Linux 5.2 Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • The NULL TTY Driver Makes It Into The Linux 5.2 Kernel

    Phoronix: The NULL TTY Driver Makes It Into The Linux 5.2 Kernel

    At first there was some concern over the practicality and use-cases for this driver, the NULL TTY driver has been merged for the Linux 5.2 kernel as part of the TTY/serial updates...

    http://www.phoronix.com/scan.php?pag...r-Lands-In-5.2

  • GreenReaper
    replied
    Originally posted by Zan Lynx View Post
    A big part of the slowdown is when the console is a graphics framebuffer. Instead of writing a byte per character it's now writing hundreds of bytes per character. And if it doesn't have hardware scroll support, it has to memmove the whole buffer for every newline.
    I significantly increased performance of 'dmsg' on my server with an MGAG-200 KMS framebuffer by switching to 8-bit colour ('[email protected]'). I imagine it's not had much work on optimization, but still, moving memory around is clearly costly.

    Serial console can be even worse for performance, though. (Of course they may be combined.)
    Still, if you're worried about a server's boot time, you're probably rebooting too much.

    Leave a comment:


  • uxmkt
    replied
    Originally posted by DoMiNeLa10 View Post
    I think the cost of syscalls is pretty significant as well, especially nowadays. It really becomes an issue when you're CPU bound, which I assume to be the case when booting up.
    Don't assume - measure. Anyhow, replacing sh scripts by systemd units probably did its deed in regard to reducing system calls, "accidentally" even.

    Leave a comment:


  • DoMiNeLa10
    replied
    Originally posted by Zan Lynx View Post
    A big part of the slowdown is when the console is a graphics framebuffer. Instead of writing a byte per character it's now writing hundreds of bytes per character. And if it doesn't have hardware scroll support, it has to memmove the whole buffer for every newline.
    I think the cost of syscalls is pretty significant as well, especially nowadays. It really becomes an issue when you're CPU bound, which I assume to be the case when booting up.

    Leave a comment:


  • Zan Lynx
    replied
    A big part of the slowdown is when the console is a graphics framebuffer. Instead of writing a byte per character it's now writing hundreds of bytes per character. And if it doesn't have hardware scroll support, it has to memmove the whole buffer for every newline.

    Leave a comment:


  • DoMiNeLa10
    replied
    Originally posted by oleid View Post
    Uh, we desperately need a boot-up time benchmark using this and the default driver! 🤣
    You'd be surprised how much time you can lose trying to write to the console. Try comparing boot times with and without the "quiet" kernel parameter.
    Last edited by DoMiNeLa10; 05-12-2019, 09:12 AM.

    Leave a comment:


  • oleid
    replied
    Uh, we desperately need a boot-up time benchmark using this and the default driver! 🤣

    Leave a comment:

Working...
X