I got three answers to my question on the round_robin_switch_rate.
These more or less confirmed what I guessed this parameter controlled
the control the time slice
Thanks to Peyton Bland, Tom Blinn, and Colin Walters. Thanks also to
Colin for pointing me in the direction of the sys_attrs man pages
which seem to be very informative and I wish I had known about them
earlier
Peyton's answer
>
> I've had similar questions about other parameters. I'm a bit of a novice
> as I just recently discovered the sysconfig and related commands (!) which
> you can use to manage parameters and configs. You might also want to look
> at
> http://tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V50A_PDF/AR
> H9GATE.PDF if you haven't already. Nothing specific on
> round_robin_switch_rate but pretty interesting. (Forgive me if I'm telling
> you some very obvious things that you already knew!)
>
Tom's answer
> According to comments in the code in kern/sched_prim.c the parameter
> round_robin_switch_rate (which is actually configured by code in the
> bsd/proc_cfg.c source) determines the switches per second when the
> scheduler policy is "round robin".
>
> Suppose you have a whole lot of intensely computational processes on
> the system; after a while, they will all gravitate to a consistent and
> relatively low scheduling priority. Since they just sit and compute,
> over time, if you never pre-empted any process, the ones that happened
> to get the CPUs would run and run and run and the others would never
> get a shot. So, the scheduler implements "round robin" scheduling, and
> gives processes a limited time slice; when a process runs out its slice,
> some other process is given a turn. The details are more complicated
> than this simplistic explanation (there are multiple priority levels,
> there are rules for moving runnable processes to different levels, there
> are rules about how some priorities are "special", and so on). Anyway,
> the round_robin_switch_rate is, I believe, used to select the default
> time slice that will be given to computationally intensive (CPU bound)
> processes before some other process is selected for execution. (What
> is REALLY scheduled is threads, not processes, but most classic UNIX
> applications are single threaded.)
>
> Using a somewhat smaller number may improve throughput on a system
> where processes switch between being CPU intensive and being blocked
> by other factors (e.g., waiting for I/O) since processes that need a
> bit more CPU to get to where they start an I/O (for instance) are a
> bit more likely to get it sooner than later; using a long cycle time
> is better when the whole workload is CPU bound for long periods.
>
> Since I have no idea what your workload is like, and I have no idea
> what sys_check is looking at in deciding to make the recommendation
> it made, I can not tell you whether you should take the advice and
> implement it. Perhaps you can examine the sys_check script and find
> out how it decided to make the recommendation it made.
>
> Tom
Colins answer
> All configurable system attributes are documented in the sys_attrs*
> reference pages.
>
> The information you need is appended.
>
> round_robin_switch_rate
>
> A value that determines (per second of CPU time) the number of context
> switches that can occur between processes with the same priority and
> the timeslice allotted to each process.
>
> Default value: 0 (100 context switches per second)
>
> Minimum value: 0
>
> Maximum value: hz
>
> The system uses the following formula to compute timeslice:
>
> timeslice = hz / number_context_switches
>
> The hz value is the timer interrupt frequency (hertz) for one second
> of
> CPU time. This value is dependent on hardware and is typically 1024
> or
> 1200. (To determine the hz value on a particular system, programmers
> can use the getsysinfo() call with GSI_CLK_TCK as the op parameter.)
>
> If round_robin_switch_rate is either 0 (zero) or greater than hz, the
> system uses 100 for number_context_switches. For example, if hz is
> 1024, the resulting timeslice is 10 milliseconds, and if hz is 1200,
> the resulting timeslice is 12 milliseconds:
>
> timeslice = 1024 / 100 = 10
>
> timeslice = 1200 / 100 = 12
>
> If round_robin_switch_rate is greater than zero and less than or equal
> to hz, then number_context_switches is set to round_robin_switch_rate.
> For example, changing round_robin_switch_rate from 0 to 20 decreases
> the number of context switches and increases timeslice by a factor of
> five:
>
> timeslice = 1024 / 20 = 51
>
> timeslice = 1200 / 20 = 60
>
> Context switching carries a certain amount of CPU overhead. If a CPU
> consistently handles many large jobs that do not complete quickly, a
> larger timeslice (and fewer context switches) may improve throughput.
> However, the tradeoff is reduced response time for any interactive
> processes that the CPU handles.
>
My Original Question
>I have just run sys_check on our AS8400 ( upgraded to V5.0A from
>V4.0F on 8 CPUs ). One of the suggestions that the sys_check out put
>has made is to increase the proc: round_robin_switch_rate. What
>exactly does this parameter do? I cant find any reference about
>round_robin_switch_rate in the V5.0A docs, and I am a little bit wary
>of changing something that I know nothing abou
--
Gwen Pettigrew
Computer Officer
Department of Earth Sciences
Cardiff University
www.ocean.cf.ac.uk/people/gwen
gwen_at_ocean.cf.ac.uk
Received on Thu Nov 23 2000 - 10:03:39 NZDT