Difference between revisions of "Fair-share scheduling"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(CPU should be written in capital)
(Tags: Mobile edit, Mobile web edit)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
Fair-share scheduling is a method of allotting CPU time to multiple processes in a defined way.  When multiple processes need a CPU, operating systems frequently allot CPU time slices on a round robin, equal time basis for processes with the same priority.  An exmaple is that if there are 4 processes wanting the CPU then each process will get 1/4 of a second every second.  This is not to say that each process will get 1/4 of a second all at one time.  Most operating systems define a time slice, something like 50 msec (arbitrary number that doesn't necessarily represent any OS) and will give each process a time slice.  So in this completely made up case, Each process will get 5 time slices every second.   
+
Fair-share scheduling is a method of allotting CPU time to multiple processes in a defined way.  When multiple processes need a CPU, operating systems frequently allot CPU time slices on a round robin, equal time basis for processes with the same priority.  An example is that if there are 4 processes wanting the CPU then each process will get 1/4 of a second every second.  This is not to say that each process will get 1/4 of a second all at one time.  Most operating systems define a time slice, something like 50 msec (arbitrary number that doesn't necessarily represent any OS) and will give each process a time slice.  So in this completely made up case, Each process will get 5 time slices every second.   
  
 
Long ago someone said that we need a way of giving people with legitimate requirements more of the time than less needy people.  "Need" often reflects what level of service the user wants to pay for.  The fair-share scheduler was born.  There have been a number of implementations over the years, but on of the most common was to simply assign weights to users such that one user may get twice as many time slices in a given time period as others.  This has been expanded often to groups so that processes belonging to a group of users would be given the same number of time slices as another group.
 
Long ago someone said that we need a way of giving people with legitimate requirements more of the time than less needy people.  "Need" often reflects what level of service the user wants to pay for.  The fair-share scheduler was born.  There have been a number of implementations over the years, but on of the most common was to simply assign weights to users such that one user may get twice as many time slices in a given time period as others.  This has been expanded often to groups so that processes belonging to a group of users would be given the same number of time slices as another group.
Line 5: Line 5:
 
For example if group A had 8 processes running and group B had 4, then each group would get half the time, meaning that each process in the A group would only get 6.25% of the time (8*6.5 = 50) and each process in group B would get 12.5% of the time.
 
For example if group A had 8 processes running and group B had 4, then each group would get half the time, meaning that each process in the A group would only get 6.25% of the time (8*6.5 = 50) and each process in group B would get 12.5% of the time.
  
There are a number of different implementations of the fair-share scheduler other than the ones described here.  I know of one that actually kept track of the accumulated time over a time period for a user/group and would use that information in it's calculations.  The theory was that if you'd been a cpu hog in the past, you might not get as much time right now.  This calculation also was also time weighted such that your share of time in the last second was much more important than a second a few minutes ago.
+
There are a number of different implementations of the fair-share scheduler other than the ones described here.  I know of one that actually kept track of the accumulated time over a time period for a user/group and would use that information in it's calculations.  The theory was that if you'd been a CPU hog in the past, you might not get as much time right now.  This calculation also was also time weighted such that your share of time in the last second was much more important than a second a few minutes ago.

Latest revision as of 17:57, 12 March 2018

Fair-share scheduling is a method of allotting CPU time to multiple processes in a defined way. When multiple processes need a CPU, operating systems frequently allot CPU time slices on a round robin, equal time basis for processes with the same priority. An example is that if there are 4 processes wanting the CPU then each process will get 1/4 of a second every second. This is not to say that each process will get 1/4 of a second all at one time. Most operating systems define a time slice, something like 50 msec (arbitrary number that doesn't necessarily represent any OS) and will give each process a time slice. So in this completely made up case, Each process will get 5 time slices every second.

Long ago someone said that we need a way of giving people with legitimate requirements more of the time than less needy people. "Need" often reflects what level of service the user wants to pay for. The fair-share scheduler was born. There have been a number of implementations over the years, but on of the most common was to simply assign weights to users such that one user may get twice as many time slices in a given time period as others. This has been expanded often to groups so that processes belonging to a group of users would be given the same number of time slices as another group.

For example if group A had 8 processes running and group B had 4, then each group would get half the time, meaning that each process in the A group would only get 6.25% of the time (8*6.5 = 50) and each process in group B would get 12.5% of the time.

There are a number of different implementations of the fair-share scheduler other than the ones described here. I know of one that actually kept track of the accumulated time over a time period for a user/group and would use that information in it's calculations. The theory was that if you'd been a CPU hog in the past, you might not get as much time right now. This calculation also was also time weighted such that your share of time in the last second was much more important than a second a few minutes ago.