| | When assigning processors in Chapter 2, we had a choice of making them unbound or bound. 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 interrupts and should be used for CPU intensive applications. Working with processors is a little tricky because you have many options, some of which you can only execute when creating a vPar, others of which require the vPar to be down before executing, so let's take a look at one of the tables from the vparstatus man page (Table 5-2): |
Table 5-2. Adding, Deleting, and Modifying Resources| Command | Description | Done with vPar Running? |
|---|
| To add resources use: (This adds component relative to what already exists if running vparmodify.) | -a cpu:path -a cpu::num [-a cpu::num] [-a cpu:::[min]:[max]] -[a cpu:path] (:::vparcreate only) -a io:path[:attr1[,attr2[...]] -a mem::size -a mem:::base:range | No Yes - relative value vparcreate only No No No | | To delete resources use: | -d cpu:path -d cpu::num -d io:path[:attr1[,attr2[...]] -d mem::size -d mem:::base:range | No Yes - relative value No No No | | To modify resources use: (This modifies to absolute number rather than relative.) | -m cpu::num -m cpu:::[min][:max]] -m io:path[:attr1[,attr2[...]] -m mem::size | Yes-absolute value No No No |
Table 5-2 shows that you have many options when adding, deleting, and modifying the resources related to your Virtual Partitions. The flexibility afforded you with Virtual Partitions is one of the most desirable aspects of working with this technology. At the same time, however; it is also one of the most confusing aspects. There are many options embedded in this table. Let's talk about assigning CPUs when creating a vPar because most of the issues related to CPUs come into play when creating a vPar. At the time of this writing, num is used in some documentation and total in others, so for the purposes of this discussion, num and total are interchangeable. path allows you to specify a specific processor to be used with a vPar. Using path will automatically assign bound processors. To add the processor at hardware path 45 to a vPar, you would use the following: -a cpu:45 min refers to the minimum number of bound CPUs. Only if you create a vPar and specify min you get min number of CPU(s) with the system assigning the hardware paths of the bound CPU(s). The following will give you two bound CPUs, the hardware paths of which are defined by the system: -a cpu:::2 max is the potential number of bound + unbound CPUs. You can, for instance, have two min and four max CPUs, which would give you two bound, as specified by the min of two, and as many as two unbound, as specified by the four max. If there are unused CPUs, they'll be allocated to your vPar, giving you a total of four. The following will give you this number: -a cpu:::2:4 num is the current number of bound + unbound CPUs. This is different from the potential number described by max. To specify three CPUs total with num, three of which are bound with min, and one at hardware path 45 with path, you would use the following: -a cpu::3 -a cpu:::3 -a cpu:45 An interesting nuance to this command is that to delete the hardware path we specified, we would issue the options in reverse order. The hardware path would come first, then the min, and finally, the num. | | In my work with vPars the most common desire is to have a min number of bound CPUs in all vPars and then move around unbound CPUs as the applications in vPars need them. For instance, when vparcreate is run, we would specify the following: |
| vparcreate -p cable1 -a cpu:::1:3 -a cpu::1 |
| | At the time of creation, cable1 will have one bound CPU only because we specified a min of one and a num of one. num is the total bound + unbound CPUs, and since we specified one for num, we'll get one bound CPU. Since max is three, we have left the door open to add as many as two additional unbound CPUs. If we have two unbound CPUs on our system, we can move them among the vPars as required with vparmodify. To remove the two unbound CPUs from cable2 and add them to cable1, we would issue the two following vparmodify commands: |
| vparmodify -p cable2 -m cpu::1 | <-- reduces cable2 from 3 to 1 | vparmodify -p cable1 -m cpu::3 | <-- increases cable1 from 1 to 3 |
We first removed the two unbound CPUs from cable2 and then added them to cable1. If the two unbound CPUs were not assigned to a vPar, we would not have to remove them from cable2 prior to adding them to cable1. unbound CPUs can be moved when a vPar is up or down but bound CPUs can be moved only when a vPar is down at the time of this writing. Although you have a lot of options for specifying and modifying CPUs, you don't have to use all of them. vPars is like any other system adminstration endeavor, keep things simple. Let's now take a look at some processors in a system.. The following listing shows the total CPUs on the L-Class system used in some of our earlier examples in the book before they were assigned to any vPars: cvhdcon3:/ # ioscan -f | grep proc processor 0 33 processor CLAIMED PROCESSOR Processor processor 1 37 processor CLAIMED PROCESSOR Processor processor 2 97 processor CLAIMED PROCESSOR Processor processor 3 101 processor CLAIMED PROCESSOR Processor The third field in this listing shows the hardware path of the processors that would be used when specifying the hardware path. After assigning processors to vPars, you'll want to confirm that indeed each vPar has in it the number of processors you specified. If we had two vPars named cable1 and cable2, each with two bound processors assigned to them, we could verify that we did indeed have two processors assigned to each vPar in a variety of ways. First we can check the processors portion only of dmesg, as shown below for cable1: cvhdcon3:/ # dmesg | grep proc 33 processor 101 processor cvhdcon3:/ # This dmesg output confirms that our vPar cable1, which has a hostname of cvhdcon3, does indeed have only two processors assigned to it even though there are four processors in the system. We can also verify the number of CPUs in a vPar by running GlancePlus and selecting the Process List screen as we have done in Figure 5-1 for cable1: Figure 5-1. CPU Report in GlancePlus Showing Two Processors The screen in Figure 5-1 confirms that we have two processors devoted to cable1 (hostname cvhdcon3) by the (200% max) shown for CPU Util rather than the four (which would have read 400%)that are in the systems. You can also run top to confirm the two processors in cable1, as shown in Figure 5-2: Figure 5-2. top Screen Shot Showing Two Processors in cable1 top clearly shows two CPUs devoted to cable1 (CPU 0 and 1 in Figure 5-2.) |