Processor Scheduling

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Posts: 62
Joined: Thu Mar 03, 2005 1:21 pm

Post by user222 »

mf wrote:
crappish wrote:Eh? Nobody wants to limit the CPU speed...
I wonder what CPU Killer was made for, then...
CPU Killer would increase the CPU temperature.

Posts: 115
Joined: Wed Jan 05, 2005 10:53 pm
Location: a thousand miles from Hinterland

Post by AcetoliNe »

I don't really think the processor scheduler in windows in inefficient. In my opinion, it does the job well.

Lengthening the processor quota to increase performance sounds logical, but you must realize that it only takes up a very small fraction of overall time.

A user-configurable scheduling system would be a very good idea, in my opinion.

I would really appreciate some factual numbers on this.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.

Posts: 92
Joined: Wed Mar 30, 2005 2:26 pm
Location: Tampere, Finland

Post by Crappish »

mf wrote:
crappish wrote:Eh? Nobody wants to limit the CPU speed...
I wonder what CPU Killer was made for, then...
I was talking about the thread in question.
Can't provoke anyone? Why bother posting?

Posts: 22
Joined: Sun Feb 20, 2005 2:27 pm

Post by cyborg »

slowing CPU is only a solution for DOS programs to run on the OS like SlowDown. it works different from that what I meant, because it USES the cpu heavily

what i wanted is good to mention in an example
there is a well known game called Ultima Online. The client from UO runs on any windows platform, needs low performance to run and so on. but it uses 100% CPU time. even on faster machines, you see the problem: on a 3200 machine 100% cpu is more power and heat, as on 500MHz... and no matter which "Threading Priority" it gets, because THREAD PRIORITY helps only in two situations: * some progs need to run besides to some CPU eating one without blocking each other, * some process needs to run in realtime or higher prio.

it doesnt help if you run ONE prog, which is eating all the CPU away for no reason. then you would have to limit cpu time. it doesnt get a "lower priority", instead the application gets only "certain amount of threadcycles". so it has no matter how much apps are running beside it, the one prog always just get its piece of cake.

if some readers are still not following, a last example: if you have a piece of cake and want to divide it between 4 persons, but one person insist getting half of the cake others get, so you use percentages. 3 persons get 87% percent of the cake thru 3, while one gets 12,5%. still depending on the cake size, this can be a lot or not as much. thats thread priority. if all are eating as much as they can, they get percentages.
different from absolute numbers, or something similar: if one person has diabetes, he wont get more than 50g of cake. if the percentage he would get is above 50g, he only gets his 50g of cake, nothing more. this is time limiting. his threading cycles are bound to 50 cycles, no matter how many are maximum.

this would also solve issue one, where some programs are crashing if they get too much cpu time at once, like old dos progs.

Posts: 34
Joined: Wed Dec 08, 2004 12:26 pm

Post by rastilin »

A user-configurable scheduling system would be a very good idea, in my opinion.
A user configurable system would be perfect, especially if it can be set to extremes in either direction and is easily accessable from a menu setting (not in the registry).
I would really appreciate some factual numbers on this.
Actually so would I.

EDIT: I just remembered that one of the main reasons I suggested this in the first place is that some people have reported sizeable performance increases after setting the scheduler to the backround setting (long, fixed threads) from Programs (Short, Variable) threads.

I intend to test this, can anyone reccommend a program?

Posts: 34
Joined: Thu Apr 07, 2005 12:49 am

Post by Alex_Ionescu »

There's absolutely nothing wrong with the scheduler, especially in the newer one used in 5.1+. The thread quantum were specifically selected for workstations and servers and act differently. There are also dynamic quanta which are sometimes applied depending on PriotitySeparation, so some threads will even have quantas of 18 or more. (Up to 6*<thread quantum base>), resulting in 36. Unlike the pathetic *x schedulers which heck, didn't even use threads until now, I think the VMS design is much better.

To answer your question, ours works completely different. It didn't even support quanta until recently, and even now the support is shaky. It doesn't support priority boosting fully, doesn't actually schedule threads, and has some really weird idle thread functionality. It also doesn't support pre-emption and it's really really slow. I have been working on fixing these issues and creating a more NT-like Scheduler, while also trying to avoid some of the bloat that it has. We've actually spent 2 weeks optimizing a single operation (which we'll actually do faster then XP, but in 2003 MS used our trick too).

Best regards,
Alex Ionescu
Kernel Developer, ReactOS


Post by Gedi »

About time you joined Alex :P

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Semrush [Bot], Yandex [Bot] and 3 guests