lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 23 Sep 2014 10:24:45 +0200
From:	Frans Klaver <frans.klaver@...ns.com>
To:	Peter Hurley <peter@...leysoftware.com>
CC:	Mark Rutland <mark.rutland@....com>, <devicetree@...r.kernel.org>,
	Alexey Pelykh <alexey.pelykh@...il.com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-kernel@...r.kernel.org>, Felipe Balbi <balbi@...com>,
	Rob Herring <robh+dt@...nel.org>,
	<linux-serial@...r.kernel.org>, Kumar Gala <galak@...eaurora.org>,
	<linux-omap@...r.kernel.org>, Jiri Slaby <jslaby@...e.cz>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 3/4] tty: omap-serial: use threaded interrupt handler

On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
> > On 09/16/2014 04:50 AM, Frans Klaver wrote:
> > > 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?
> > 
> > Not everyone cares enough about serial to dedicate kthreads to it :)
> 
> Fair enough. In that light, we might not care enough about other
> subsystems to dedicate kthreads to it :). Selectable seems reasonable in
> that case.
> 
> 
> > >> 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.

Doing the threaded interrupt change on the 8250 driver doesn't seem as
trivial. Unless I'm mistaken, that version of this patch would mess with
all other 8250 based serial drivers, if it's done properly. Incidentally
I did try using threadirqs, but that didn't give my any significant
results. I mostly noticed a difference in the console.


> > > 
> > >>> 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.
> > 
> > System work should not keep irqs from being serviced. Even 174us is a long
> > time not to service an interrupt. Maybe console writes are keeping the isr
> > from running?
> 
> That's quite possible. I'll have to redo the test setup I had for this to
> give you a decent answer. I'll have to do that anyway as Sebastian's
> 8250 conversion improves.

I haven't had time yet to look into this any further. I'll accept that
this patch may fix a case most people aren't the least interested in.
I'll also happily accept that I probably need a better argumentation
than "this works better for us".Would it make sense to drop this patch
and resubmit the other three? As I mentioned in the previous run, I
think these are useful in any case.

Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ