[BUG] increased us/sys-load due to tty-layer in 2.6.38+ ?!

[Steffen Trumtrar]

Hi!

I noticed a problem with the tty subsystem on ARM. Starting with 2.6.38+ load
on the serial connection causes a 10-15% increase in system/userspace load.
This doesn't change up to v3.9-rc4.

The following setup was used:

  telnet && screen microcom -p /dev/ttyUSB0
        |                           +--------+
        |-------------->------------|----+   |
    +-------+<---------<------------|----+   |
    |       |       +------+        |        |
    |  UUT  |<-USB->| FTDI |<-UART->|        |
    |       |       +------+        |   PC   |
    +-------+                       +--------+
        ^
        |
  telnet && top -d1

The unit under test (UUT) is connected via USB->FTDI->UART to a PC. On the PC
a "while true; do find /; done" produces some random output.
I connect to the UUT via telnet and then open a serial connection to the PC
in a screen session, seeing the output produced on the PC. Then screen gets
detached. So, basically, what I'm trying to do is producing load only on the
USB->FTDI->UART connection and not on the UUT itself.
Then another telnet connection is opened, to monitor the UUT with "top -d1".
As UUT an imx27, kirkwood and an AT91 were used.

To find the "offending" code, I bisected v2.6.38..v3.0 which gave the following
top output (non-scientifically, I know. But the switch in load distribution is
obvious nevertheless):

2.6.38           Cpu(s):  3.8%us,  1.9%sy,  0.0%ni, 94.3%id
2.6.38+          Cpu(s):  1.9%us,  3.8%sy,  0.0%ni, 94.3%id
last good commit Cpu(s):  1.9%us,  2.8%sy,  0.0%ni, 95.3%id
first bad commit Cpu(s):  4.8%us, 14.5%sy,  0.0%ni, 80.6%id
2.6.39-rc4       Cpu(s): 10.5%us,  8.9%sy,  0.0%ni, 79.8%id
3.0              Cpu(s): 15.9%us, 19.6%sy,  0.0%ni, 62.3%id

This resulted in
        f23eb2b2b28547fc70df82dd5049eb39bec5ba12
        tty: stop using "delayed_work" in the tty layer

as possible cause. Reverting this commit by hand in v3.8 showed a load distribution
similar to 2.6.38.
What I haven't done, is measure if the load is really increasing or if top only
tells me so. Maybe the algorithm to calculate this somehow produces different
results because of the switch from schedule_delayed_work to schedule_work?
So, is this a bug, a feature, a symptom,...?

Regards,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/