[ros-kernel] Process scheduler / timer resolution

[Waldo Alvarez Cañizares]

Hi Hyperion:

From: ros-kernel-bounces at reactos.com on behalf of KJK::Hyperion
Sent: Wed 3/10/2004 5:46 PM
To: ReactOS Kernel List
Subject: RE: [ros-kernel] Process scheduler / timer resolution


At 22.51 10/03/2004, you wrote:
>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.

This will be my absolutely last comment on Linux: seeing it *finally*,
after more than ten years of development and well into the new millenium,
implement a constant-time scheduler, threads, PnP and a HAL (features that
Windows NT has had since day one - except PnP), I officially welcome it in
the world of real, modern operating systems (it's something that really
makes one ponder. Really, a successful operating system is *not* defined by
its kernel. Stallman has a sound point in calling it GNU/Linux). You
finally made it, little penguin. Those stubby legs and wings of yours must
be a real annoyance. 

Wow, lots of flamethrowings to Linux. Ok every one is free to have their own opinion. But I think one of the worst things of Linux is the lack of modularity, and the lack of compatibility. Anyway I don't pretend to discuss good/bads of linux, I pretend to get the best of every operating system around and put it in ReactOS. Now, I don't think the NT scheduler is something to follow. I have seen NT almost freeze with high priority threads. Sure! a couple of days ago just to give an example I attached pipetunnel (the one in tools) and guess what? 10 minutes and the machine was totally unresponsive(win2k). The solution? Hard Reset :( . I have never seen Linux behave in such a way. Not even with heavy load and I was not even using the new scheduler. IMO the NT scheduler should be trown in the toilet. I think The quantum should be variable, at least should depend on the number of threads in the system. ie more threads = smaller quantums to get a more responsive system (responsiveness is something users appreciate, well at least I do) and also should depend on the number of CPUs (including logical CPUs) ie more CPUs = bigger quantums.

Anyway, comparison with the VMS/NT scheduler, *the*
scheduler we should implement: 

Could you give some explanation here. I would like to know about it, and why do you have such a point of view. Is there some feature not present in the Linux scheduler? You say it is the way but you don't say why it is.

>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)

check. The bitmap is called "ready summary" in the VMS/NT scheduler, but
it's not for constant execution time, it's for optimization. Doing an
IsListEmpty() on each ready queue is O(<priority levels>) = O(32) = O(1),
but it's just slower: first, it requires <priority levels> memory accesses
vs <priority levels>/<bits in a word> = 1, and second, it's not uncommon
for CPUs to have fast bit scan opcodes (the x86 does)

Interesting. Thanks for the info. BTW I was taking a look and they have an implementation neutral (in c) to do the bit scanning you talk about. It says somethig like -Taken from the book "A hacker's delight"-

>threads do not constantly switch from CPU to CPU (they keep affine as much
>as possible)

check (no, not really sure. But it would be so stupid otherwise that I just
assume it)

The previous Linux scheduler sometimes caused that. They say it in the document.

>no CPU is idle when there is job to do

check

>interactive process are temporarily boosted and the quantum reduced (so
>interactive processes answer right away even with high CPU load)

check

Now for the *real* features: how many priority levels? how does it prevent
starvation? does it have real-time priority levels, i.e. not affected by
boosting? does it support threads waiting for multiple events? does it
support boosting the threads awakened by the firing of an event? 

I'll try to answer those questions with another e-mail since those are detailed questions. But it does prevent starvation. Give me some days I'll get deeper into the Linux Scheduler.

will it keep our I/O completion ports at least as efficient as those of Windows NT?
etc.

I'm not sure if that could be answered without implementing it, but provably yes.

Also remember that the Linux scheduler is right there waiting to be adapted. The other schedulers you talk about are waiting to be implemented. I think is a better idea to get that code already implemented and tweak it if needed. Don't you think?

Best Regards
Waldo Alvarez
_______________________________________________
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: 7290 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040311/43b620d0/attachment-0001.bin