Re: [PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> > On 09/15/2014 10:00 AM, Frans Klaver wrote:
> >> At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> >> rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> >> this to about 170 overflows in 10 minutes.
> > 
> > Why is the threadirqs kernel boot option not sufficient?
> > Or conversely, shouldn't this be selectable?
> 

I wasn't aware of the threadirqs boot option. I also wouldn't know if
this should be selectable. What would be a reason to favor the
non-threaded irq over the threaded irq?

> Also, do you see the same performance differential when you implement this
> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> 

I haven't gotten Sebastian's driver to work properly yet on the console.
There was no reason for me yet to throw my omap changes on top of
Sebastian's queue.

> > PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> > latency in excess of 250us?

At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
haven't done any measurements on the interrupt latency though. If you
consider that we're sending about 1kB of data, 240 times a second, we're
spending a lot of time reading data from the uart. I can imagine the
system has other work to do as well.

This doesn't mean that we're not interested in Sebastian's driver
anymore though. We really want that dma support.

Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux