Re: [PATCH] local_irq_disable removal

[Gene Heskett]

On Saturday 11 June 2005 20:09, Sven-Thorsten Dietrich wrote:
>On Sun, 2005-06-12 at 01:44 +0200, Thomas Gleixner wrote:
>> On Sat, 2005-06-11 at 13:51 -0700, Daniel Walker wrote:
>> > On Sat, 11 Jun 2005, Ingo Molnar wrote:
>> >
>> > Interesting .. So "cli" takes 7 cycles , "sti" takes 7 cycles.
>> > The current method does "lea" which takes 1 cycle, and "or"
>> > which takes 1 cycle. I'm not sure if there is any function call
>> > overhead .. So the soft replacment of cli/sti is 70% faster on a
>> > per instruction level .. So it's at least not any slower .. Does
>> > everyone agree on that?
>>
>> No, because x86 is not the whole universe
>
>Das Dehnt sich aus.
>
>Even if there is a case of minimal expansion in the overhead on some
>architecture, it may justify the effort for a certain class of
>applications which require known interrupt response latencies.
>
>The concept model here is, that you will have all interrupts running
> in threads, EXCEPT one or more SA_NODELAY real-time IRQs. Those
> RT-IRQs may be required to track satellites, manage I/O for a QOS
> or RF protocol stack, shut down a SAW, or a variety of RT-related
> services.

Lets add the operation of 4 or more stepper motors in real time for 
smaller milling machines.  There, the constraints are more related to 
maintaining a steady flow of step/direction data at high enough 
speeds to make a stepper, with 8 microsteps per step, and 240 steps 
per revolution, run smoothly at speeds up to say 20 kilohertz, or 50 
microseconds per step, maintaining that 50 microseconds plus or minus 
not more than 5 microseconds else the motors will start sounding 
ragged and stuttering.

That would correspond to (if my calculator's button pusher didn't 
screw up) 625 rpm at the motor shaft.  Thats faster than it would 
ever move while actually cutting, but would certainly be valuable in 
reaching the next point to start a fresh cut pass in a reasonable 
length of time.  Adeos is apparently able to do this now, given a rip 
snorter cpu of 2GHZ or more real clock speed.  Cutting the rep rate 
to 200 u-secs, cuts the motor speeds down into the 150 rpm range, but 
is then quite usable and the cpu has some time to do other things, 
like pay attention to the mouse and its clicks, or refresh the screen 
on a 500+ mhz box.  100 u-sec on a 1400 mhz Athlon, and the rest of 
the machine, while slow, is 100% usable.

These are the time constraints, generally speaking, it takes to run a 
small milling machine under the control of emc.  And this is the 
range we would expect for much of the machine controller world.

One of the complaints we (I at least) have in the adeos environment, 
is that the cpu is equally hogged, and the machine lags, full time 
even if the emc state is stopped.  This I think is an emc problem 
moreso than a kernel problem, in that emc should be capable of 
dynamicly adjusting the RT loops timeing, so that if the machine is 
in stop, the machine gives up its cpu to other tasks, making the 
machine much friendlier.  This is something needed by emc IMO, but 
the experts in emc may have other limits I don't know about.

Anyway, my $0.02 on the guaranteed 'deterministic' aspect of this.
Currently running V0.7.48-10 in mode 3 with hardirq threading turned 
off as turning it on still kills tvtimes video dma.  Its running 
quite decently in fact.

>The IRQ-disable-removal allows that the RT-IRQ encounters minimal
>delay.
>
>Often, that IRQ will also wake up a process, and that process may
> have some response-time constraints on it, as well.
>
>SO that's one model that is helped by this design.
>
>
>
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/