public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Burkhard Schölpen" <bschoelpen@web.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Reduce IRQ latency or revise hardware?
Date: Thu, 13 Apr 2006 11:17:56 +0100	[thread overview]
Message-ID: <1144923476.9989.28.camel@localhost.localdomain> (raw)
In-Reply-To: <615249858@web.de>

On Iau, 2006-04-13 at 08:42 +0200, Burkhard Schölpen wrote:
> 1. Is it somehow possible to fulfill the realtime requirements of the
> hardware by e.g. a realtime kernel patch or some kernel configuration
> fine tuning (at the moment I need a maximum hardware latency of about
> 100 microseconds)?

I don't believe you can 100% reliably achieve 100uS on an x86 board just
because of the possible SMM, cache and tlb miss worse cases combined
with the IRQ latency of the hardware. If you have other PCI devices on
the bus then you will have real fun getting hear it.

Hand tuning all the configuration and using rtlinux as the bottom layer
might just about do it if you avoided other PCI devices that can be slow
to respond (eg ATA disk and many video cards). You'll also need a board
with no SMM mode code in use so probably ACPI disabled, and possibly
have to pick the board to suit the needs.

It may also be far easier to hit such deadlines if the chip is wired
fairly directly to one of the embedded processors so you don't have
busses in the way and you have a fast IRQ response.

> Again I would like to underline that the main task is to get the
> interrupt handler invoked early enough, so I can get data out of a
> hardware FIFO. If this FIFO produces overflows, I get into big
> trouble, because the following data stream will be corrupted and the
> hardware must be reset. The programmer of the FPGA says that the
> buffer size is already at the maximum.

The other highly latency sensitive stuff like that I've seen appears to
all bus master and have a FIFO to front that which just handles PCI
delays. That way an IRQ just means one of the bus master buffers is
full.

Alan


      reply	other threads:[~2006-04-13 10:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13  6:42 Reduce IRQ latency or revise hardware? Burkhard Schölpen
2006-04-13 10:17 ` Alan Cox [this message]

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=1144923476.9989.28.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=bschoelpen@web.de \
    --cc=linux-kernel@vger.kernel.org \
    /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