Binding of CPUs in VPars

[Ralph Grothe]

Hello again,

I'm new to VPars.
So far I've only read the manpages
(especially of vparresources), but I guess
this isn't enough as some basic concepts seem still unclear to me.

I understood that during a vparcreate you would (together with other resources) assign the min. and max. Nos. of CPUs to the vpar,
which appear as bound (i.e. eq min) and unbound
(i.e. num - min)
e.g.

vparcreate -p vptest -a cpu::4 -a cpu:::2:4 -a cpu:1/14 -a cpu:1/15 ...

Currently vparstatus shows this layout for vptest (I prefer the machine format here because ITRC textareas flatten multiple whitespace which eually impairs human readability)

# vparstatus -Mp vptest
vptest:Up:Dynamic,Autoboot,Nosearch:/stand/vmunix::2/4;;1.14,1.15;2.10;:2.0.0.2.0.6.0.0.0.0.0 BOOT
,2.0.0.3.0.6.0.0.0.0.0 ALTBOOT,2.0.0.1.0,2.0.8.1.0,2.0.10.1.0,2.0.12.1.0,2.0.14.1.0,2.0.0.2.1:;793
6:N

or parsed out, these bound CPUs

# vparstatus -Mp vptest|cut -d\; -f3|tr . /|tr , \\012
1/14
1/15

and these unbound CPUs

# vparstatus -Mp vptest|cut -d\; -f4|tr . /|tr , \\012
2/10

What I haven't yet understood is how an addition of a "floating" CPU from the pool of unbound CPUs is accomplished.
Is this done automatically without human interaction by the vpar manager when it senses that CPU usage would better require the addition of another CPU,
or does the admin need to fumble about with the vparmodify command?

I could for instance (for a running vpar)

# vparmodify -p vptest -a cpu::1

# echo $?
0

# vparstatus -Mp vptest|cut -d\; -f4|tr . /|tr , \\012
2/10
2/15

and a new unbound CPU 2/15 shows up.
But according to what I have read in the manpages this doesn't mean that I really added the CPU (i.e. made it interruptable).
So what's the use of vparmodify then?

Regards
Ralph

[Pete Randall]

Ralph,

First, the admin has to manually add processors with vparmodify. Quoting from Marty Poniatowski's "hp-ux virtual partitions" book,

"Bound CPUs are dedicated to a vPar and can't be dynamically removed or added to vPars. Bound CPUs handle I/O interrupts and should therefore be used with I/O-intensive applications. Unbound CPUs can be dynamically added and removed from vPars. Unbound CPUs do not handle I/O interrups and should be used for CPU intensive applications."

So your answer is no, you can not make an unbound CPU interruptable.


Pete


Pete

[Steven E. Protter]

Shalom Ralph,

I've been reading the same book.

Unbound cpu's should be able to be taken out of one vpar and moved to another vpar.

Bound one's are stuck unless you break and rebuild the vpar.

Seems to me you are using the right command.

Good Luck,

SEP

[Ranjith_5]

Hi Raiph,

Bounded CPUs are the minimum required CPUs for a VPAR to operate, Although we normally define more number of unbound CPUs in a vpar for doing work load management.

during a peak load period if one f the vpar in a nPAR is giving low performance due to the lack of processer resources we can take unbound cpus from other vpars using the vpar modify.

bounded CPUs cannot be moved to anopther system using vparmodify command.


Regards,
Syam

[Ralph Grothe]

Just to make sure I got it correctly.

Say, I wanted to steal a CPU from vptest
(that has 2 unbound) and give it to vplech
(that now has 4 whereof 2 unbound vs. 2 bound)

# vparstatus -vp vptest|head -15
[Virtual Partition Details]
Name: vptest
State: Up
Attributes: Dynamic,Autoboot,Nosearch
Kernel Path: /stand/vmunix
Boot Opts:

[CPU Details]
Min/Max: 2/4
Bound by User [Path]:
Bound by Monitor [Path]: 1.14
1.15
Unbound [Path]: 2.10
2.15


So first I take it from vptest

# vparmodify -p vptest -d cpu::1

# vparstatus -vp vptest|head -15
Name: vptest
State: Up
Attributes: Dynamic,Autoboot,Nosearch
Kernel Path: /stand/vmunix
Boot Opts:

[CPU Details]
Min/Max: 2/4
Bound by User [Path]:
Bound by Monitor [Path]: 1.14
1.15
Unbound [Path]: 2.10

[IO Details]


Then I give it to vpleach which currently has

# vparstatus -vp vplech|head -15
[Virtual Partition Details]
Name: vplech
State: Up
Attributes: Dynamic,Autoboot,Nosearch
Kernel Path: /stand/vmunix
Boot Opts:

[CPU Details]
Min/Max: 2/4
Bound by User [Path]:
Bound by Monitor [Path]: 0.10
2.14
Unbound [Path]: 0.11
2.11


# vparmodify -p vplech -a cpu::1
vparmodify Error: "-a cpu::1": Total CPUs would exceed configured maximum.

Ok, can we increase the total num for vplech then?

# vparmodify -p vplech -m cpu::5 -m cpu:::2:5
vparmodify Error: "-m cpu::5": Total CPUs would exceed configured maximum.

Hm, if do have to bring down vplech first to increase the max CPUs then I ask myself what the whole virtual partitioning is good for.
Especially since the servers have all bays fully equipped so that hardware partitioning would have been feasible as well.

[Alzhy]

Say you have 2 vpars - vparA (4 CPUs total - 2 bound/2 unbound - capable of up to 16) and vParB (2CPUs- capabale of upto 16).

To increase vParB's CPU count to 4 and "stealing" from vParA:

Reduce vParA to 2 CPUS:

vparmodify -p vparA -m cpu::2

vparstatus -A (to see the freed up CPUs)

Add the freed up CPUs to vparB:

vparmodify -p vparB -m cpu::4

[Pete Randall]

Ralph,

vPars is good for more finely tuning resources. With nPars, the CPUs/memory/IO per partition will be split evenly and there is no way to change that. The vPars give you *some* extra control. My chief complaint with vPars is that you can no longer do Ignite backups to tape and, for that reason alone, I'm trying to move away from using them.


Pete

[Alzhy]

vPars is good in environments that have dynamic CPU requirements. Say you have a large Server split into 2 vpars. By day -- your Online Environment can get the lions share of the CPUs. By night - your DSS/Warehouse environment gets them.

With NPars - you will not have that flexibility.

Note though that memory cannot be dynamically moved.

[Duncan Edmonstone]

Sorry if I'm missing something here Ralph, but if you'd set the min/max CPUs in each vPar to 2/6 I think that would have allowed you to use those unbound CPUs.

These min/max values have to be set with the vPar down, but once set, you can then move unbound CPUs around dynamically without any reboots

HTH

Duncan