From: "Lawrence E. Bakst" <ml@iridescent.org>
To: Eugene Surovegin <ebs@ebshome.net>
Cc: ppcembed <linuxppc-embedded@ozlabs.org>
Subject: Re: Interrupt prioritization on linux for ppc440
Date: Mon, 18 Apr 2005 13:54:44 -0700 [thread overview]
Message-ID: <p06210215be89c5d708df@mail.iridescent.org> (raw)
In-Reply-To: <20050418172532.GB25352@gate.ebshome.net>
At 10:25 AM -0700 4/18/05, Eugene Surovegin wrote:
>On Mon, Apr 18, 2005 at 10:01:02AM -0700, Lawrence E. Bakst wrote:
>> I just want to say that in certain applications critical interrupts
>> can be put to good use. There are issues you have to deal with when
>> you use them. I wonder if any of the people saying that they "really
>> don't think it's worth it" have ever had to meet any real time
>> interrupt latency constraints?
>
>You know, it'd help if instead of some general statements, you gave
>real example and explained, why default stuff doesn't work for you.
I'd point out that your own statements were pretty general to start off with. I would have liked to elaborate but unfortunately the work is an ongoing research effort for a client under NDA so I can't say very much.
>Also, it'd be nice if you explained how you dealt with infrastructure
>problems I mentioned in my previous e-mail.
We didn't deal with them as we have a kind of special case. I am not trying to minimize the importance of that issue in the general case.
>
>Answering your question about "real time interrupt latency
>constraints", I have to ask what _exact_ latencies you need, and why
>do you think Linux can provide hard real-time guarantees?
We are trying to get to an interrupt response time of substantially less than what you mention below. In this case "substantially" means between 2 and 3 decimal orders of magnitude.
>
>And yes, I work for company which makes VoIP hardware, and soft
>real-time qualities of 2.4 Linux kernel (preempt, low-lat) are good
>enough for us (~1-5 ms average scheduling latency), without any need
>of critical interrupts.
We're operating in different environments and doing different things. With the kind of response time we're trying to achieve we can't afford to schedule anything.
The only point I was trying to make is that the critical interrupt facility was useful to us. That was it. It's not clear to me that within the constraints of how Linux works, the various infrastructure issues, as well as politics, that it could be made useful to others in a generalized form.
Best,
leb
>
>--
>Eugene
next prev parent reply other threads:[~2005-04-18 20:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-15 21:36 Interrupt prioritization on linux for ppc440 Shawn Jin
2005-04-15 22:12 ` Eugene Surovegin
2005-04-15 23:09 ` Shawn Jin
2005-04-16 0:50 ` Eugene Surovegin
2005-04-18 21:14 ` Shawn Jin
2005-04-18 22:06 ` Eugene Surovegin
2005-04-18 23:11 ` Shawn Jin
2005-04-19 0:27 ` Eugene Surovegin
2005-04-18 17:01 ` Lawrence E. Bakst
2005-04-18 17:25 ` Eugene Surovegin
2005-04-18 20:54 ` Lawrence E. Bakst [this message]
2005-04-18 22:27 ` Eugene Surovegin
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=p06210215be89c5d708df@mail.iridescent.org \
--to=ml@iridescent.org \
--cc=ebs@ebshome.net \
--cc=linuxppc-embedded@ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.