Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267010AbSL3RRo>; Mon, 30 Dec 2002 12:17:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267014AbSL3RRo>; Mon, 30 Dec 2002 12:17:44 -0500
Received: from [203.199.93.15] ([203.199.93.15]:26378 "EHLO
	WS0005.indiatimes.com") by vger.kernel.org with ESMTP
	id <S267010AbSL3RRm>; Mon, 30 Dec 2002 12:17:42 -0500
From: "arun4linux" <arun4linux@indiatimes.com>
Message-Id: <200212301716.WAA30139@WS0005.indiatimes.com>
To: "Roger Larsson" <roger.larsson@norran.net>
CC: <linux-kernel@vger.kernel.org>
Reply-To: "arun4linux" <arun4linux@indiatimes.com>
Subject: Re: Re: Lowering Latency
Date: Mon, 30 Dec 2002 22:54:53 +0530
X-URL: http://indiatimes.com
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3098
Lines: 84

<<I assume that the only thing the driver does on an interrupt is to wakeup the application? 

>>Yes. it wakes up the sleeping threads.

<<Can the interrupts arrive faster than once per 1/50 s = 20 ms?
>>Yes. But at least 3000 interrupts have to get processed by both ISR and application thread.

<<But it is REQUIRED that your application runs with SCHED_FIFO and its memory locked.
>>Did you mean dynamic memory allocation in the application? or something else?

<<But do not use 
schp.sched_priority = sched_get_priority_max(SCHED_FIFO);
since there are generally no SCHED_FIFO processes running and the highest levels should be reserved for really important stuff...
>>I use the SCHED_RR (real-time threads) in the application.

<<What is in the PCI registers that the application uses - data? 

>>It uses both the device registers as well as data.

Making the driver smarter is also not possible in our case as we are porting it and we try to imitate another OS as much as possible for code maintanece requirement.

Warm Regards

Arun

"Roger Larsson" wrote:




On Wednesday 25 December 2002 23:09, you wrote:
> <> << latency and not much more. 
> 
> I need to process a minimum of 3000 interrupts per minute generated by a
> PCI based controller.
> And my development environment is RedHat 8.0. I can't change both of these.
> And the application is tightly coupled with the driver. Driver exports the
> PCI base addresses to the application using mmap and application accesses
> the card directly.
> 
> Arun
> 

Lets see...
3000 interrupts per minute => 50 per second, should not be a problem in driver
code. But...

I assume that the only thing the driver does on an interrupt is to wakeup the 
application? Then you have the need for low latency... What is the worst 
case? Can the interrupts arrive faster than once per 1/50 s = 20 ms?
Why I ask is because 20 ms is on the average OK for a standard kernel.
But if you like to use the file system on the same time it will be a problem.
But it is REQUIRED that your application runs with SCHED_FIFO and
its memory locked.

see
http://www.gardena.net/benno/linux/audio/
it is old, the standard kernel is better now. But do not use
schp.sched_priority = sched_get_priority_max(SCHED_FIFO);
since there are generally no SCHED_FIFO processes running and
the highest levels should be reserved for really important stuff...

What is in the PCI registers that the application uses - data? Is it data
acuisition application? If not, try to make the driver smarter - it helps.

/RogerL

-- 
Roger Larsson
Skellefte?



Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com

 Buy the best in Movies at http://www.videos.indiatimes.com

Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now!

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