Very simple linux Scheduler question

Very simple linux Scheduler question

Post by Jason Johnso » Sat, 27 May 2000 04:00:00



Hello,

I have question about the linux scheduler.  I have been looking
through the source code, and as far as I can tell
it looks like, that each process has only a certain
amount of ticks it is allowed to run.  When it runs out, it will not be
scheduled again until all other runable processes have also
used all of there ticks, at which point all the runable processes
have there quantums recalculated and the whole thing starts over.
Am I correct here (I am obviously ignoring processes that do IO,
or get put to sleep in general)?

Thanks in advance for indulging my curiosity.

Jason

 
 
 

Very simple linux Scheduler question

Post by Jason Johnso » Tue, 30 May 2000 04:00:00


Hrm.  This must be a really stupid question, or a really *e, based on
the number
of answers I have recieved.

>Hello,

>I have question about the linux scheduler.  I have been looking
>through the source code, and as far as I can tell
>it looks like, that each process has only a certain
>amount of ticks it is allowed to run.  When it runs out, it will not be
>scheduled again until all other runable processes have also
>used all of there ticks, at which point all the runable processes
>have there quantums recalculated and the whole thing starts over.
>Am I correct here (I am obviously ignoring processes that do IO,
>or get put to sleep in general)?

>Thanks in advance for indulging my curiosity.

>Jason


 
 
 

Very simple linux Scheduler question

Post by John Gluc » Tue, 30 May 2000 04:00:00



> Hello,

> I have question about the linux scheduler.  I have been looking
> through the source code, and as far as I can tell
> it looks like, that each process has only a certain
> amount of ticks it is allowed to run.  When it runs out, it will not be
> scheduled again until all other runable processes have also
> used all of there ticks, at which point all the runable processes
> have there quantums recalculated and the whole thing starts over.
> Am I correct here (I am obviously ignoring processes that do IO,
> or get put to sleep in general)?

> Thanks in advance for indulging my curiosity.

> Jason

That's one scheduling mechanism but there are a few others available...
The April 2000 issue of Linux Journal has an article that may interest
you.

--
John Gluck  (Passport Kernel Design Group)

(613) 765-8392  ESN 395-8392

Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.

 
 
 

Very simple linux Scheduler question

Post by Jason Johnso » Tue, 30 May 2000 04:00:00


Thank you very much!  I had no idea that such a document existed.  Most of
the people I talked to
said there was no documentation like this on the Linux kernel.

However, the book did not seem to answer my question.  I am speaking about
the code in the
kernel that, after it has ran through all the processes calculating there
"goodness" and assigning
the biggest one to "c", a test of "c" is done to make sure that it is not
zero.  If it is, they go through
the list again assigning the counters to be the value of there priority.
This seems to indicate that
every process will run until it has used all its quantum and then not run
again until all other processes
have done the same (again I am ignoring the IO, ques, etc.).

Jason

-----Original Message-----


Date: Monday, May 29, 2000 5:21 PM
Subject: Re: Very simple linux Scheduler question


>> Hrm.  This must be a really stupid question, or a really *e, based
on
>> the number
>> of answers I have recieved.
>[...]

>It isn't a stupid question but did you read the fine manual?
>This is explained in "The Linux Kernel" from David A Rusling:

>http://www.veryComputer.com/

>Section "4.3 Scheduling"
>subsection "Process selection":

>Process selection

>The scheduler looks through the processes on the run queue looking for
>the most deserving process to run. If there are any real time
>processes (those with a real time scheduling policy) then those will
>get a higher weighting than ordinary processes. The weight for a
>normal process is its counter but for a real time process it is
>counter plus 1000. This means that if there are any runnable real time
>processes in the system then these will always be run before any
>normal runnable processes. The current process, which has consumed
>some of its time-slice (its counter has been decremented) is at a
>disadvantage if there are other processes with equal priority in the
>system; that is as it should be. If several processes have the same
>priority, the one nearest the front of the run queue is chosen. The
>current process will get put onto the back of the run queue. In a
>balanced system with many processes of the same priority, each one
>will run in turn. This is known as Round Robin scheduling. However, as
>processes wait for resources, their run order tends to get moved
>around.

>--
>Frederic S. PARAIN - PhD Student - Projet SOLIDOR
>IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France

>"Everything should be as simple as possible, but not simpler"

 
 
 

1. Simple NUMA Scheduler rev4 (1/2)

Attached is my simple NUMA scheduler patch.  It has been split into
two separate patches, the first part is a modification to
find_busiest_queue to favor runqueues for processors on the same
node.  Care was taken to ensure that the change to find_busiest_queue
would not change the selection criteria used for non-NUMA machines.

The second patch adds logic to exec to place the exec'd task on
the least loaded runqueue, thus avoiding the need to move the task
to a different (potentially off-node) runqueue in the immediate
future.  This patch needs the first patch to apply, but could be
easily changed to apply to a kernel without the first patch.

There are no functional changes between these two patches and the
patch provided for 2.5.43.  As stated then:

On NUMA systems these two changes have shown performance gains
in the 5 - 10% range depending on tests.  Some micro-benchmarks
provided by Erich Focht which stress the memory subsystem show
a doubling in performance.

The simple NUMA scheduler patch has been included in the
linux-2.5.44dcl1 kernel so has seen additional testing with no
issues reported.  I would welcome additional testers or inclusion
in other 2.5 kernel trees.  

--

Michael Hohnbaum                      503-578-5486

  sched44rev4.part1
4K Download

2. ppp weirdness

3. Simple NUMA scheduler patch

4. Crontab script problem - email to a phone

5. [RFT] simple deadline I/O scheduler

6. NFS/NIS bandwidth and cpu usage

7. Simple NUMA Scheduler - rev 2

8. Prepare Your Web Server For High Traffic - NetscapeWorld

9. [RFT] simple deadline I/O scheduler

10. Simple NUMA Scheduler - rev 2

11. Linux scheduler question

12. A simple question deserving a simple answer

13. a simple sed question ( there all simple :> )