how to set a processor

[Wahyono_1]

i have two processors running in an alpha server. both are running but i cannot assign one of the processor to a processor set.
so if we check with 'pset_info', only one processor is running. what are the ways to set these processors.

[Ravi_8]

Hi,

Look into man pages of 'psradmin' or 'psradm'. It explains well

[Michael Schulte zur Sur]

Hi,
you can do it in this sequence:
pset_create
pset_assign_cpu 2 1
2 is the new processor set, 1 the cpu you assign to it.

greetings,

Michael

[Hein van den Heuvel]

>> i cannot assign one of the processor to a processor set.


Why not? Do you not know how to do it, or does it give an error? Which commands used?
What does 'pset_info -v' show?

More importantly... what real problem are you trying to solve.
I suspect that dividing a 2-cpu box into 2-psets makes it inflexible and poorly performaning for some tasks.
That would be because psets are exclusive, non-overlapping.

You may want to consider runon to force a select process/command on a selected processor. Maybe toss some renice (nasty) in the mix to enforce near exclusive usage... if the process needs it. This will hopefully reduce context switches just about as much, and give you some extra performance through affinity while keeping the system flexible to do say backups without having to change those psets again.

hth,
Hein.

[Ross Minkov]

I second the previous post.

Also check cpu_mask (or something like that) SRM variable at the >>> prompt. Make sure it enables all the CPUs.

Regards,
Ross

[Wahyono_1]

Hi all,

thanks for your help.
i have tried some of your suggestions.
if i use 'assign_cpu_to_pset', nothing happens.
if i use 'psradm', it says 'permission denied (login using root).
i haven't tried other options, cause it's in the running system...i have to consider the impact

[Michael Schulte zur Sur]

Hi,

have you done it in the sequence I posted?
Can you post pset_info?

thanks,

Michael

[Wahyono_1]

Dear Michael,

yes i have already tried that.
it says 'too many processors requested'

rgrds
wahyono

[Michael Schulte zur Sur]

Hi,

please post the pset_info output. I suspect as Ross that you are not running all cpus. Does monitor show all cpus?

greetings,

Michael

[Ross Minkov]

You don't need to shutdown the system to check the value of a SRN variable. Do this from the OS:

/sbin/consvar -g cpu_enabled

Let us know what the value was.

Regards,
Ross

[Ross Minkov]

Sorry I meant to say SRM (not SRN) in my prev post....

Here is what this cpu_enabled SRM variable is all about...

To disable one or more cpus at the console level, you change the setting of the
"cpu_enabled" console environment variable. The variable is essentially a bit
vector with one bit for each cpu. The default value is to have all cpus enabled
(that is, all the bits of the bit vector are set to "1"). To disable a cpu, you
need to set the corresponding bit to zero and then execute the "init" command or
power cycle the system.

A bit of explanation about the "cpu_enabled" variable:

For a system that can be configured with up to 4 cpus, the corresponding bit
vector of that system's "cpu_enabled" variable has 4 bits:

1 1 1 1
cpu 3 2 1 0

and they are all set to 1s therefore the corresponding value of the
"cpu_enabled" variable is F (hexadecimal).

If you wanted to disable CPU 2 for instance, you would change the bit vector
thus:

1 0 1 1
cpu 3 2 1 0

by setting the "cpu_enabled" console variable to A (hexadecimal). This you do
by entering the command "set cpu_enabled A" at the console (">>>") prompt.

CPU0 is always enabled. Even if you set cpu_enabled to 0 CPU0 is still enabled.
If you set cpu_enabled to 2 -- both CPU0 & CPU1 are enabled (as if it was set to 3).


HTH,
Ross

[Hein van den Heuvel]

Wahyono,

Please help us help you by giving us concrete and exact data to work with.

- pset_info output
- psrinfo output

>> if i use 'psradm', it says 'permission denied (login using root).

What are you asking psradm to do? Is the processor actually there? (psrinfo!)

>> i haven't tried other options, cause it's in the running system...i have to consider the impact

Well... making pset's effectively takes the assigned cpu completely away from the running systems. That's about the niggest impact you can make!

The 'runon' + renice suggestion has just about no side impact.

Good luck,
Hein.

[Wahyono_1]

Guys,

these are the outputs of some commands.
i really appreciate your help

rgrds
Wahyono

[Hein van den Heuvel]

Thanks for that listing.
It shows somethign 'odd'

There is a line missing for cpu# 1 in:
-----------
cpu # running primary_cpu pset_id assigned_to_pset
0 1 1 0 11/26/2004 11:07:58
------------

It is my understanding that if cpu# 1 was not in any pset, it would be reported as pset -1

Here is how it works on my test system:
# uname -a OSF1 kelrin V5.1 2650 alpha
# pset_create
pset_id = 2
# pset_assign_cpu 2 2
# pset_info
number of processor sets on system = 2
pset_id # cpus # pids # threads load_av created
0 3 69 277 0.00 11/18/2004 13:42:28
2 1 0 0 0.00 12/10/2004 00:55:22

total number of processors on system = 4

cpu # running primary_cpu pset_id assigned_to_pset
0 1 1 0 11/18/2004 13:42:28
1 1 0 0 11/18/2004 13:42:28
2 1 0 2 12/10/2004 00:55:40
3 1 0 0 11/18/2004 13:42:28

# pset_destroy 2
processor set 2 has active processors/tasks/threads assigned to it.
destroy anyway? (y/n): y
# pset_info

number of processor sets on system = 1

pset_id # cpus # pids # threads load_av created
0 4 69 277 0.00 11/18/2004 13:42:28

total number of processors on system = 4

cpu # running primary_cpu pset_id assigned_to_pset
0 1 1 0 11/18/2004 13:42:28
1 1 0 0 11/18/2004 13:42:28
2 1 0 0 12/10/2004 00:56:32
3 1 0 0 11/18/2004 13:42:28

#


You may have found a bug,
Or just an unfortunate series of trail.

Hate to say this, but I would try again after a reboot at your earliest convenience.

In the mean time, assuming CPU #1 is actively used and not wasted (top or monitor?) I woudl continue on and see if runon/renice can address your needs without psets

Hein.