[ros-kernel] Process scheduler / timer resolution

[Waldo Alvarez Cañizares]

Hi:
 
Now that you talk about it. Why don't you pick up the Linux scheduler? Is inside a file named sched.c written by Ingo Molnar. If there is a list with the great features of Linux sorted by relevance, I would put the scheduler somewhere in the first 2.
 
Ultra scalable (as they say and as it is, put all the CPUs you want, The machine will be faster)
all operations are O(1) (they use a small bitmap somewhere)
threads do not constantly switch from CPU to CPU (they keep affine as much as possible)
no CPU is idle when there is job to do
interactive process are temporarily boosted and the quantum reduced (so interactive processes answer right away even with high CPU load)
background processes get a higher quantum to increase performance.
configurable (there are some macros at the beginning) and tested (of course it runs in lots of machines already), documented too (take a look at docs)
works great for uniprocesors.
Resuming... A jewel.
 
Take a look, it is not a very big file.
 
Best Regards
Waldo Alvarez

________________________________

From: ros-kernel-bounces at reactos.com on behalf of Mike Nordell
Sent: Tue 3/9/2004 8:18 AM
To: ReactOS Kernel List
Subject: Re: [ros-kernel] Process scheduler / timer resolution



Andrew Greenwood wrote:

[snipped large over-quote]

> I just recall reading somewhere that a faster timer interrupt rate
improves
> multitasking performance.

That is never the case. Ever. Performance is always reduced with increased
interrupt rates. Always.

> Perhaps this is not the issue here, and, like you
> said, ReactOS doesn't use a thread quantum, so presumably having thread
> quantums would improve things?

Implementing thread quantum would mean (perhaps even much) less time would
be spent serving each timer interrupt - leaving more time for the threads to
actually do the work they're supposed to do. IMNSHO that would indeed be an
improvement.

But I'm still not sure what you intended with "improve things", especially
the "things". Would you care to elaborate?

> The only practical reason for finer interrupt-tuning would be for
> lower-latency with realtime things like audio programs.

1. Realtime has a very specific meaning. NT (and therefore ROS) can not be
realtime as-is.
2. If you have a specific application where you need >100
thread-switches/second, just to handle your audio application, I think you
- need a real-time OS such as QNX, vxWorks, or even DOS(!)
or
- need a device-driver in ROS

> Or am I missing something?

I don't know, and to not begin speculating whether that's the case or not
perhaps you could explain a scenario you think a higher thread-switching
rate/lower latency would be required. Please take into account that if you
really need to be the "top dog" on every schedule, you're free to run the
process at "Realtime" priority.

/Mike

_______________________________________________
Ros-kernel mailing list
Ros-kernel at reactos.com
http://reactos.com/mailman/listinfo/ros-kernel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6522 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040310/b5849e30/attachment.bin