On Sat, 29 Sep 2001, Peter Jay Salzman wrote: > begin: Nicole Carlson <[EMAIL PROTECTED]> quote > > On Sat, 29 Sep 2001, Peter Jay Salzman wrote: > > > i came across an article 'low latency in the linux kernel' written for > > > o'reilly's website. here's a quote i find curious: > > > > > > under certain circumstance, it may be possible to run an application > > > in a condition known as setuid root. as the name implies, this > > > condition sets the user's ID to root status, raising the application's > > > execution to real-time scheduling.
Kind of hard to find anything correct after the last comma. Setuid root is only related to permissions and has nothing directly to do with scheduling. > > > > > > this is NOT my understanding of setuid root executables. if this were the > > > case, nice-ing a setuid executable would be meaningless since the application > > > would get the attention of the kernel whenever it wants attention. > > > also, there would be no need for 'real time linux' since running an app as > > > setuid root would imply real time scheduling. > > > > > > > I agree with you; I'm suspicious of O'Reilly's quote there. "Real-time" > > is not a synonym for "really fast"; it has a very specific meaning, and it's > > rather non-trivial to implement. In a real-time OS, processes are guaranteed > > to finish by a predefined interval. The Linux kernel doesn't implement > > that[1]--if memory serves, it uses several levels of priorities (so > > kernel-space stuff gets priority over user-space stuff) and round-robin > > within priority levels. It's possible (though I find it unlikely) that a > > setuid root program runs in the kernel-space priority queue, but even that > > isn't enough for true real-time scheduling. "Suspicious" is too lenient. It is dead wrong (surprising, given the credits below). And no, setuid doesn't move your process from userspace to kernel space. Look at http://www.linuxdevices.com/articles/AT8073314981.html > > thanks, nicole. that last sentence was the one i was trying to grope for. > that even kernel space processes aren't real-time. and it certainly doesn't > mean "very fast". > > thanks for the confirmation. btw, aside from this curious statement, the > article was pretty good, and pointed me to the most intriguing web site: > > http://www.gardena.net/benno/linux/audio/ > > apparently, this guy wrote a couple of things of interest: > > 1. a kernel audio latency test. measures the latency of audio within linux. > he shows that audio latency on linux can be made much smaller than on > a windows system. meaning that linux is a better audio platform than > windows (aside from the fact that there's no powerful easy-to-use audio > software written for linux yet. sox is NOT user friendly!) > > 2. a patch to lower latency within the kernel itself. the patches got > rejected by linus as being inelegant. but he shows benchmarks, and > they're more than quite good. unfortunately, he seems to have stopped > support for the patch; no 2.4 support. > > his latency tester doesn't compile on my system; gcc doesn't seem to > recognize a spinlock_t data type. obviously, a header file was split since > the 2.2 days and the defintion isn't being read in. spinlock_t is defined in $LINUXSRC/include/linux/spinlock.h. In 2.2.19, this includes $LINUXSRC/include/asm/spinlock.h. In 2.4.9 it is right in spinlock.h, but there are conditionals based on SMP support. > i'm trying to track the problem down right now, and sent an email to the > author in the offchance that he's still maintaining this stuff. Be careful playing with scheduling. You run the risk of making your system less (possibly much less) controllable when you make mistakes. This stuff can get out of hand even in embedded systems, where you have only a handfull of tasks to accomplish, and in a general purpose computer you could find it doesn't work very generally anymore. --------------------------------------------------------------------------- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k ---------------------------------------------------------------------------
