does reducing timeslice increase system speed

Does reducing timeslice increase system speed how to#

So that's how you change the timeslice value. The -D flag is most useful when you want to build an installable mksysb image, but don’t necessarily want all of your customized tunables to carry over to your new installations. Incidentally, you can reset whole groups of tunables―say, every schedo or vmo tunable―to their defaults by applying the -D flag, like this:ĭepending on the subsystem you’re working with, you may see messages telling you a whole bunch of tunables have been returned to their defaults. So if you had to reboot your system, run a bosboot or remount filesystems to make your initial changes stick, you’ll need to do the same when resetting that value to its default. The only catch is that, as it was on the way up, so shall it be on the way down. And again, -d can be applied to any tunable. You should get a message that says, “Setting timeslice to 1.” A quick check with a schedo -FL timeslice will confirm that the value has indeed returned to its default. Whether you’re working with CPU, memory, storage or networking tunables, applying -d will reset any value to its default. Should we reverse our command sequence, this time gradually adjusting our timeslice value downward until it’s back at the default level? Nope. Do a schedo -FL timeslice to see where you wind up.Įven on a test box, you don't want a timeslice value to remain in the billions, so let's dial it down. You should eventually get a warning message telling you you’re trying to exceed timeslice’s maximum value. Now go up to the maximum value this could be 2 billion or more, depending on the clock speed of your particular POWER processor. You may or may not begin to see effects on your system, namely, typing response. We're altering system behavior here, so we can never be too cautious. Rather than simply recalling your previous command for this exercise, you should actually type out each iteration. To get the feel of how timeslice is adjusted, repeat the schedo -o timeslice= command above, incrementing the timeslice value in powers of ten: from 1,000 to 10,000 to 100,000, etc. See the CUR column? That’s your current timeslice value. Use this command to confirm that the value was changed: Now let’s just adjust the real-time value of timeslice upwards―say, by a factor of 1,000. See the NI―for Nice Value―column? Processes that run with a fixed priority have a double-dash there.) (An aside: Although process studies are beyond the scope of this article series, note that you can determine if a given process has fixed priority by issuing ps -el.

Remember this when you begin measuring the effects of adjusting timeslice on your test system. On that note, probably the biggest takeaway from this brief help study of timeslice is that adjusting this value will only impact fixed priority processes. Of course it's a good idea to fully understand what a tunable does before fiddling with it. The value refers to the total number of clock ticks in a timeslice and only affects fixed-priority processes. Increasing this value can reduce overhead of dispatching threads. The number of clock ticks a thread can run before it is put back on the run queue. Figure 2 shows us the output of a help command, run against timeslice. Our unit of value is “clock ticks,” and the capital D at the far right tells us the timeslice value is dynamic it can be adjusted freely without having to reboot the system. We next see the possible range of values we can apply to a timeslice, from 0 up to about 2 billion. Note the name of each tunable, its current, default and bootime values, as well as its minimum and maximum values. In figure 1, we see the output of a schedo -FL timeslice command, issued as root. Recall that timeslice is used to essentially fatten a 10-millisecond (ms) period by increasing the number of CPU clock ticks that can run in that same 10-ms period. Now let's go turn some dials and flip some switches! In this first tuning example, we’ll call upon an old friend, the CPU scheduling option (schedo) known as timeslice. I'm sure you understand the perils of tinkering with a live production system, but let's make it clear: This sort of experimentation could lead to some really bad situations, so don't do it.

Now in part 3, we're ready to put this leaning into practice.įirst, a quick note of caution: The things I describe here should only be done on a test AIX system, a sandbox that management won’t miss if it crashes and burns. In summary, we learned what the tunables do.

Does reducing timeslice increase system speed how to#

Then I told you how to determine each tunables’ default value, along with the valid range of values that can be applied. Previously in this article series, I identified the many kernel tunables in AIX that control the performance of CPUs, memory, storage and networking.