> If you have a 16-processor server and you wanted to provide multiple CPUs to
> say two different Virtual Servers running on the box, how would you do that?
> Seems like VS can only use one CPU.
>

>...
>The host will
>schedule multiple threads across all of your available CPUs but your
>guests will only ever see a single CPU.

> Paul Adare <(email address - cut out)> wrote:
>
>>...
>>The host will
>>schedule multiple threads across all of your available CPUs but your
>>guests will only ever see a single CPU.
>
> Which begs the question, whence threads?
>
> Are we talking about threads in the client OS? Seems unlikely. More
> likely, one thread per VM. Which would imply that the only way to get
> multiple threads, and thereby use multiple CPUs, would be to run multiple
> guest OSs.
>
> It's possible VS uses separate threads to handle VM-related tasks like the
> emulation of NICs, hard drives and networks, I suppose. Especially
> networks.
>
> This is interesting, in one particular case, because I know of a used
> quad-CPU server that has relatively slow CPUs. With four of them, though,
> it becomes significant exactly how VS spreads its workload. My guess
> would
> be that it would be far better to have a single fast CPU.
>
> /kenw
> Ken Wallewein
> K&M Systems Integration
> Phone (403)274-7848
> Fax (403)275-4535
> (email address - cut out)
> www.kmsi.net

> You will notice that the vssrvc.exe (on the host) has several threads, for
> my setup I'm seeing approximately 4-6 threads per virtual machine. Take a
> look using Performance Monitor.
>
> Regarding using a host with multiple processors, using a dual cpu
> configuration would be better than a quad setup due to the general
> performance loss using multiple processors.
>
>
>
> /Ragnar
>
>
>
> <(email address - cut out)> wrote in message
> news:(email address - cut out)...
>> Paul Adare <(email address - cut out)> wrote:
>>
>>>...
>>>The host will
>>>schedule multiple threads across all of your available CPUs but your
>>>guests will only ever see a single CPU.
>>
>> Which begs the question, whence threads?
>>
>> Are we talking about threads in the client OS? Seems unlikely. More
>> likely, one thread per VM. Which would imply that the only way to get
>> multiple threads, and thereby use multiple CPUs, would be to run multiple
>> guest OSs.
>>
>> It's possible VS uses separate threads to handle VM-related tasks like
>> the
>> emulation of NICs, hard drives and networks, I suppose. Especially
>> networks.
>>
>> This is interesting, in one particular case, because I know of a used
>> quad-CPU server that has relatively slow CPUs. With four of them,
>> though,
>> it becomes significant exactly how VS spreads its workload. My guess
>> would
>> be that it would be far better to have a single fast CPU.
>>
>> /kenw
>> Ken Wallewein
>> K&M Systems Integration
>> Phone (403)274-7848
>> Fax (403)275-4535
>> (email address - cut out)
>> www.kmsi.net
>
>

>How is it that using more CPUs gives you performance loss? Isn't more
>always better???

> In message <(email address - cut out)> "Spin" <(email address - cut out)>
> wrote:
>
>>How is it that using more CPUs gives you performance loss? Isn't more
>>always better???
>
> No. There is significant overhead in deciding which threads go on which
> processors, plus the context switches to get them there.
>
> Also, keep in mind that although you have more CPUs, you still generally
> only have one motherboard (and it's related components) that all the
> CPUs need to share. You'll often find that you have CPUs sitting around
> under utilized because the rest of the system can't feed the CPUs work
> fast enough.
>
> If you have a roughly static number of threads/processes, and that
> number is equal to the number of CPUs, you can achieve some significant
> (measurable) performance improvements by locking threads to individual
> processors to avoid all the context switches.
>
> However, this doesn't generally scale in the real world.
>
> --
> It's not an optical illusion. It just looks like one.

>Thank you. May I impart on your wisdom for one more question. Is a context
>switch the event that causes the motherboard to switch the interrupt request
>to another processor?