linux-kernel - Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup & DMA

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]

Message-ID: <3efb10970712191232t4e1a1148q2c634b004421a685@mail.gmail.com>
Date:	Wed, 19 Dec 2007 21:32:44 +0100
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Haavard Skinnemoen" <hskinnemoen@...el.com>
Cc:	"Andrew Victor" <linux@...im.org.za>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	"Russell King" <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org, kernel@...32linux.org
Subject: Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup & DMA

Hello,

> preempt-rt can disable interrupts for 300 us?

I am not sure if it really is an interrupt lock that long, but on
these ARM cores I still run into latencies that large. I tried using
latency_trace to figure out where they come from, but that tool even
reports interrupt locks up to 10 ms while those surely do not exist
(the 2nd in size reported is about 300us). So, those tools are buggy
on AT91 as well, and I do not trust them completely yet.. (They even
do not compile cleanly, conflicts in headers, warnings etc. Maybe
those tools are not used very much outside x86)

So, I still have a long way to go to make Preempt-RT to run on these
cores just as good as preempt-rt runs on X86, although I am sure that
I never will reach the <30us as I have on x86.

> If so, then I guess there's really no way to avoid a few overruns.

And if DBGU is used as a terminal, it should be no problem at all, or
someone has to slow down the baudrate a bit.
I only get this overrun under very heavy system load (CPU load 99%,
with one single thread running at RT-prio 99, taking chunks away of
99/100ms.) and then throw in a big file of many MBs in the terminal.
But, as long as the read part still runs in hard-irq context, it
should keep up, unless interrupts are locked too long.

> > Notice that without these interrupt handler splitup, it was much, much
> > much worse...
>
> Ok, that's good I guess.

Yep, that _is_ good.

> > So, for me it is not a big deal, because it is just a terminal, and
> > with my shaky fingers I usually do not type that fast ;-))
> If you do, you just need to switch to one of the USARTs instead of the
> DBGU so that you can use DMA :-)

:-)

> We need to fix the break- and error handling though. But my vacation
> starts tomorrow, so I probably won't be able to fix it until next year.

In that case, I wish you very good holiday, and a happy new-year.
It was very pleasant working with you on this driver.

I probably see you again on the list next year.

Kind Regards,

Remy
--
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/