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 [email protected]
>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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
