Rik van Riel wrote:
|> On Wed, 8 Dec 1999, jcordina wrote:
|> > Well I surely have made my measurements and it takes quite a lot of
|> > instructions (actually hundreds) for an Unix system to deschedule a
|> > thread amd move on to the next thread.
|>
|> > A call to the kernel takes about 1 us to access the protected kernel
|> > space whilst I am talking in the order of ns.
|>
|> So you want to do an operation that's too expensive in
|> kernel space and hope that it will become magically
|> inexpensive when you do the same thing in userspace?
That is absolutely possible. We implemented user space scheduling in the
Irix framework where significant performance improvements within a
multithreaded application were seen simply because we didn't have to
cross the kernel boundry to execute the same code. In fact in many
cases there was less work to do as the code in the kernel had to
support processes generally and a thread library would know more and
could do less. The basic philosophy was that the kernel would schedule
cpus to processes and the process would schedule its threads onto those
cpus. Not that I am suggesting the Linux should do this, but I still think
it was a pretty cool idea.
|> If your timing contraints are so narrow that it doesnt,
|> then you'll (most probably) need RTlinux anyway...
I don't buy that. There are many latency bound applications that would work
perfectly fine with standard Linux if only they could guarantee that they
could 'own' a cpu, i.e. bind them selves to it and exclude everyone else
from using it.
Simon.
--
Simon Patience Phone: (650) 933-4644
Silicon Graphics, Inc FAX: (650) 962-8404
1600 Amphitheatre Pkwy Email: [EMAIL PROTECTED]
Mountain View, CA 94043-1389
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
