2 or 4 cpu's running Info

Mike Segel wrote: > > David L. Kosenko wrote: > > > > Mike Segel wrote: > > > With SMP, neither cpu is *idle*. They both or all, pull procs from the > > > same > > > stack. > > > > Yes, but if you only have one CPU VP and nothing else really running on the > > machine, the second cpu will be idle a lot of the time. Two cpus cannot run > > the same process simultaneously. > > > Same Process true. But, when is there only one process on the stac? > Hmmm... Let me think. This is UNIX right? How many system procs are > running? > Lets take a quick look : > inetd > init > nfsd > gettys > syncer > syslog > (OK, I think I made my point.) > > > Other's have pointed out situations where a 2-proc is best tuned as a uni, such as when > > your applications run on the same machine as the server. Also consider those platforms > > where kernel async i/o is not supported. If you are doing a lot of i/o in your app, the > > aio vps are going to be very active, and could force the cpu vps to get context switched > > more than is ideal. In those situations, it may be worthwhile to tune with the single > > cpu vp and leave the other physical processor for this other server work. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This type of thinking is flawed. You can't control which CPU gets what > in an > SMP machine. Some OSs allow you to limit a task or set of tasks to one > CPU. > But they do not limit other processes to NOT use that CPU. (IBM AIX > 4.1.3 does this.) > > Look, context switching occurs naturally in all multitasking OSes. Yes > virgina there > is *overhead* in a context switch. (Lets define Overhead is time spent > doing a systems management task within the kernel.) Because the amount > of *overhead* is not a linear > progression, adding cpus will not yield a linear performance gain. Tasks > switch easily. Threads do not. Since a thread shares a memory segment > with its parent, > it will be blocked when it tries to run on a different CPU and it's > parent is running. > (mutex lock) > (And vice a vera.)[Note: This is all theoretical. Different > implementations of operating systems will vary.] Context switching will > occur for one of three reasons: > 1) The time slice is up. > 2) Blocked resource, or waiting for a resource like I/O. > 3) Pre-empted by the kernel. (Deadlock detection/advoidence, watchdog > alert, etc ...) > [I'm sure there is something else but hey, what do I know?] > > BTW, are aio vps threads or tasks. If threads, then how does Informix > handle > mutex between aio vps? > > Depending on how the OS is written, and how the software is written, > performace > and tuning will vary. There are no set in stone rules. Its still a gut > and intuitive > process. My point was that individuals were thinking in terms of each > physical > cpus to be separate on an SMP box. The point of SMP is that they should > be thinking > in terms of a single cpu. > Now clustering on the other hand .... > [Then you have a whole different ball game and process migration means > alot! ;-] > > -- > > Dave Kosenko, Informix Professional Services > > Mikey, Some guy found off the street! > #include <std_disclaimer.h>