mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Hironobu Ishii" <hishii@soft.fujitsu.com>
To: "Russell King" <rmk+lkml@arm.linux.org.uk>,
	"Taku Izumi" <izumi2005@soft.fujitsu.com>
Cc: <akpm@osdl.org>, <linux-kernel@vger.kernel.org>
Subject: Re: performance-improvement-of-serial-console-via-virtual.patch added to -mm tree
Date: Tue, 13 Sep 2005 20:44:37 +0900	[thread overview]
Message-ID: <00b601c5b858$8a8c4ad0$dba0220a@CARREN> (raw)
In-Reply-To: <20050913091740.A8256@flint.arm.linux.org.uk>

Hi Russel,

I am working with Taku,

> On Thu, Sep 08, 2005 at 04:47:32PM +0900, Taku Izumi wrote:
>> >I don't think we want this.  With early serial console, tx_loadsz is
>> >not guaranteed to be initialised, and may in fact be zero.
>> 
>> >Plus there's no guarantee that the FIFOs will actually be enabled, so
>> >I think it's better that this patch doesn't go to mainline.
>> 
>> Our server has a virtual serial port, but its performance seems to be poor.
>> It takes 10 seconds to output 4000 characters (from kernel) to serial
>> console. By applying my patch, its peformance could be improved. ( 0.4
>> seconds / 4000 characters output), so I think it is useful to use FIFO at
>> serial8250_console_write function like transmit_chars function. Where
>> should I correct in order to use FIFO?
> 
> The problem is that we don't know:
> 
> * if there is a FIFO
> * what size the FIFO is

I understand tx_loadsz is practical TX FIFO size. 
If there is no FIFO, tx_loadsz becomes 1.
Is it wrong?
  
 - tx_loadsz is properly initilized in autoconfig().
 - FIFO is enabled in serial8250_clear_fifo() called from autoconfig(),
   if FIFO exist.
 - autoconfig() is called from serial8250_isa_init_ports().
 - serial8250_isa_init_ports() is called from serial8250_console_init() etc.
 
I can't find the problem you are pointing out.

> * if it has been initialised
> * how much data is already contained in the FIFO

Right, we can't know how many byte exist in the FIFO.
So this patch is waiting the FIFO becomes empty at first
by calling "wait_for_xmitr(up)".
(This is the same logic with original.)

After TX FIFO become empty, we can decide the available 
TX FIFO depth by up->tx_loadsize.

>        for (i = 0; i < count; ) {
>                int     fifo;
>
>                wait_for_xmitr(up);
>                fifo = up->tx_loadsz;
>                /*
>                 *      Send the character out using FIFO.
>                 *      If a LF, also do CR...
>                 */
>                do {
>                        serial_out(up, UART_TX, *s);
>                        fifo--;
>                        if (*s == 10) {
>                                if (fifo > 0) {
>                                        serial_out(up, UART_TX, 13);
>                                        fifo--;
>                                } else {
>                                        /* No room to add CR */
>                                        wait_for_xmitr(up);
>                                        fifo = up->tx_loadsz;
>                                        serial_out(up, UART_TX, 13);
>                                        fifo--;
>                                }
>                        }
>                        i++;
>                        s++;
>                } while (fifo > 0 && i < count );
>        }


> 
> So we can't really blindly initialise the FIFO in the console write
> method.  Neither can we initialise it in the console setup.  If we
> could initialise it, we can't blindly load 16 bytes into the FIFO
> at a time.
> 
> I don't think it's technically practical to use the FIFO for the
> console and still have a reliable serial port.
> 
> -- 
> Russell King
> Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
> maintainer of:  2.6 Serial core
> -

Best regards,
Hironobu Ishii

  reply	other threads:[~2005-09-13 11:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200509072146.j87LkNv8004076@shell0.pdx.osdl.net>
     [not found] ` <20050907224911.H19199@flint.arm.linux.org.uk>
2005-09-08  7:47   ` Taku Izumi
2005-09-13  8:17     ` Russell King
2005-09-13 11:44       ` Hironobu Ishii [this message]
2005-09-13 11:53         ` Russell King
2005-09-13 12:02           ` Russell King
2005-09-13 13:07             ` Hironobu Ishii
2005-09-15  5:20               ` Taku Izumi
2005-09-13 12:18           ` Hironobu Ishii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00b601c5b858$8a8c4ad0$dba0220a@CARREN' \
    --to=hishii@soft.fujitsu.com \
    --cc=akpm@osdl.org \
    --cc=izumi2005@soft.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®