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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      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 Guest; 12 May 2019, 09:12 AM.

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              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 ('video=1280x1024R-8@75'). 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.

              Comment

              Working...
              X