Re: Reduce Solaris context switches possible?

"Alan Coopersmith" <alanc_at_CSUA.Berkeley.EDU> wrote in message news:ajlsq0$k8a$1_at_agate.berkeley.edu...

> It's much more complicated than that - you can edit the scheduling class
> dispatch table, which includes the time slice for each priority level
> and the bits that control what priority level processes go to when they
> are put back into the queues. This is done with dispadmin, but I
> wouldn't recommend doing it without learning a whole lot about how the
> Solaris scheduler works, via a kernel/tuning class or book.
>
> --
> ________________________________________________________________________
> Alan Coopersmith alanc_at_alum.calberkeley.org
> http://soar.Berkeley.EDU/~alanc/ aka: Alan.Coopersmith@Sun.COM
> Working for, but definitely not speaking for, Sun Microsystems, Inc.

This "guy" had probably heard this in a SA-400 course. The dialog goes something like this:

The kernel dispatcher makes adjustments to thread priorities based on how they are interacting with the system. A thread that is using up all of it's time quantum (CPU hog) will be assigned a longer time quantum the next time it is assigned to a processor, but at the expense of having it's priority lowered (by default 10 lower than it was when it exceeded it's time quantum). A thread that has been sleeping (blocking waiting on I/O for example) will have it's priority increased but at the expense of having it's time quantum lowered.

So if you know that you have a CPU bound application, you can use dispadmin to alter this dispatch table to get the thread back on the CPU quicker. The hope is that the thread gets back on the CPU before the data in the ecache or perhaps even the L1$ is overwritten by another thread. Some people find the default degradation of 10 for a CPU bound thread to be too high moving it quickly down the run queue and ensuring that the L1$ and L2$ will need to be reloaded.

The SA-400 course book explains how to create a hybrid dispatch table using the current values and earlier versions of Solaris where the dispatch table was tuned for batch processing by Sun Microsystems

Any changes made with dispadmin will not survive a reboot. One must save the modified dispatch table and then call for it in a run control script.

That said..... I agree with all the previous advice. Get Cockcroft's book, I also recommend McDougals Solaris Internals book, good info regarding the dispatch table. Attend a performance management course, and look for other areas first, tune the I/O, UFS out of the box needs quite a bit of tweaking to run better. Look at memory and tune there first. After all of this, then, maybe, adjust the kernel dispatcher. Just remember that unless you save the table and call dispadmin via a RC script, all your modifications are lost after a reboot.

Brian Received on Sat Aug 17 2002 - 16:37:17 CDT