Announcement

Collapse
No announcement yet.

Linux Serial Console Driver Lands Patch For Possible ~25% Performance Improvement

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

  • Linux Serial Console Driver Lands Patch For Possible ~25% Performance Improvement

    Phoronix: Linux Serial Console Driver Lands Patch For Possible ~25% Performance Improvement

    It's not an area of Linux hardware performance we normally look at, but thanks to a Red Hat engineer discovering very low serial console performance, there is an improvement queued up for introduction in Linux 5.17.....

    https://www.phoronix.com/scan.php?pa...ial-16550-FIFO

  • #2
    16550 UARTs FIFO support was missing all that time?
    Holy moly. I thought it's 2022 already, but it's more like 1982 there then.

    Comment


    • #3
      The UART FIFO queue can reduces CPU load (fewer interrupts). But even pre-486 PCs can easily max out a 16550 sending a byte at a time?

      Not sure how it could make that big a speed difference as quoted in the article?

      Task switching that broken? Insert Spectre/Meltdown/RandomCPUBugOfTheWeek?

      I'm confused.

      Michael
      Phoronix
      Michael typo: "cosnole"

      Comment


      • #4
        Originally posted by JEBjames View Post
        Not sure how it could make that big a speed difference as quoted in the article?
        Basically this means controller is sending bytes faster than polling sender can feed it.
        It's not polling in a tight loop, it's rescheduled. And the poller is not scheduled in intervals short enough on specific machine it seems.

        OR the UART (or its emulation by i.e. BMC) is so crazy that it doesn't bring the related 'buffer empty' bit to 'empty' state immediately after transmitting the buffered byte, like nobody ever expected someone no less crazy would be sending stuff at high speeds without FIFO in polling mode
        Alex/AT
        Senior Member
        Last edited by Alex/AT; 12 January 2022, 05:32 PM.

        Comment


        • #5
          Originally posted by Alex/AT View Post
          Basically this means controller is sending bytes faster than polling sender can feed it.
          It's not polling in a tight loop, it's rescheduled. And the poller is not scheduled in intervals short enough on specific machine it seems.

          OR the UART (or its emulation by i.e. BMC) is so crazy that it doesn't bring the related 'buffer empty' bit to 'empty' state immediately after transmitting the buffered byte, like nobody ever expected someone no less crazy would be sending stuff at high speeds without FIFO in polling mode
          a phoronix bar chart and benchmark will settle this

          Comment


          • #6
            Wonder if this would affect 'virtual' serial ports as well, as commonly seen on server platforms where you have a virtual serial console accessible via the BMC? Or is it only for 'real' hardware UART chips?

            Comment


            • #7
              Originally posted by JEBjames View Post
              But even pre-486 PCs can easily max out a 16550 sending a byte at a time?
              I think interrupt latency is one those (few) things that hasn't really improved much since the 486 days. Doesn't really matter that a modern CPU can shovel stuff orders and orders of magnitude faster than a 486, if the interface only allows copying a single byte between each interrupt.

              Comment


              • #8
                Originally posted by onlyLinuxLuvUBack View Post

                a phoronix bar chart and benchmark will settle this
                There is a 50% chance this chart answers the question.

                https://xkcd.com/688/

                Comment


                • #9
                  Afaik,
                  The 16550A (or 16550, as its called) FIFO has 16 byte FIFO buffers.
                  It can receive up to 14 bytes (or send 16 bytes) before it has to interrupt the CPU.
                  This are the oldest devices around, from the time of 486's, Pentiums, or newer, by other word's...obsolete

                  Nowadays, the buffers are superior to 1KB, I believe, but it will depend on the hardware you have..

                  Comment


                  • #10
                    Originally posted by Alex/AT View Post
                    16550 UARTs FIFO support was missing all that time?
                    Holy moly. I thought it's 2022 already, but it's more like 1982 there then.
                    I am going to guess. Linux started out as a grad-student project in 1989, and was kinda flaky and missing a lot of features, especially hardware support for the first decade of its life. By the time it got going, no one really cared about UART anymore, and most serial consoles aren't performance intensive, as its the last thing anyone generally uses for sending large amount of data, and USB, ethernet, bluetooth all became well maintained.

                    Until now, someone has a usecase for sending high volume RS-232 serial data in 2022, that has performance needs, interesting.

                    Comment

                    Working...
                    X