Messages in this thread | | | Date | Mon, 15 Nov 1999 09:33:42 +0100 (MET) | From | Roman Zippel <> | Subject | Re: linux interrupt handling problem |
| |
Hi,
On Fri, 12 Nov 1999 yodaiken@chelm.cs.nmt.edu wrote:
> "atomic macros" + "more flexible" + "zero interrupt latency" + > "scale better" etc -- these are terms that do not express any > technical information, but rather express an emotional state of > hopefulness and confidence which is admirable but leaves the reader > just as ignorant as before.
I know and I can't really change this right now, as I'm still working on this, so I have zero test results, I'll have to see until I have results (BTW the rt topic wasn't my original reason for this thread).
> Look at global_cli and think again. > If what you mean by "atomic macros" is a set of lock-free and/or > atomic operations on data structures, that's a laudable project and > one that needs to be done.
The atomic macros make the compare-and-swap or load-and-store instructions generally usable and only fall back to spinlocks if they're not available.
> The optimization goals of rt and non-rt synchronization code are totally at > odds with each other. For example, the Linus/Ingo design of x86 > semaphore locks is to-the-bone efficient for non-RT, but is > terrible for RT since worst case behavior is poor. Ted's bottom halves > solve several synchronization problems for Linux kernel, at the > expense of introducing latency. And etc.
I know of these problems and I still want to keep the hard real time part in the kernel, but to achieve the low interrupt latency, I want to introduce the atomic macros, so that we will have synchronization mechanism semaphores, spinlocks and atomic macros, all three don't require to turn off interrupts and can still be fast, if correctly implemented. By emulating sti()/cli() as in RTLinux more and more parts could be changed step by step to make use of the three synchronization mechanism, this is of course a long term plan and I hope to improve overall perfomance by this, not to make it worse, but of course I still have to see how it turn out.
bye, Roman
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |