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/