I have marked a number of CPUs in a machine no-intr using psradm.
I can't see that this has changed anything on disk anywhere, so I am
slightly worried that this change will not persist across a reboot.

Will it?  I am running Solaris 10, and the manuals are drawing a blank.
If not, is there a canonical place to put this initialisation?

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere

On 2006-04-11, Ceri Davies <ceri_usenet@submonkey.net> wrote:
> I have marked a number of CPUs in a machine no-intr using psradm.
> I can't see that this has changed anything on disk anywhere, so I am
> slightly worried that this change will not persist across a reboot.
>
> Will it?  I am running Solaris 10, and the manuals are drawing a blank.

The answer to that question is "no".

> If not, is there a canonical place to put this initialisation?

Still open!

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere

Ceri Davies <ceri_usenet@submonkey.net> writes:
> On 2006-04-11, Ceri Davies <ceri_usenet@submonkey.net> wrote:
>> I have marked a number of CPUs in a machine no-intr using psradm.
>> I can't see that this has changed anything on disk anywhere, so I am
>> slightly worried that this change will not persist across a reboot.
>>
>> Will it?  I am running Solaris 10, and the manuals are drawing a blank.
>
> The answer to that question is "no".
>
>> If not, is there a canonical place to put this initialisation?
>
> Still open!

Hi Ceri :-)))

I'm not sure about a "canonical" place, but an /etc/init.d script that
runs before important stuff fire up (i.e. network interfaces) seems ok.

If you feel funky, an SMF service somewhere after milestone/single-user
would be nice too.

Perhaps psrset and psradm should be persistent?

What are your thoughts on that?

- Bart

In article <1144816749.555175.3780@u72g2000cwu.googlegroups.com>, bart.smaalders@gmail.com <bart.smaalders@gmail.com> wrote:
>
> Perhaps psrset and psradm should be persistent?
>
> What are your thoughts on that?

I'd be in favor for this. We use this to put the processors into a
specific and known state until otherwise needed in a different state.

E.g. we use it to take erroring processors offline to defer swapout to a
less disruptive time or do other special performance-related tricks with
psradm.

I can see how this might be used in certain situations to stay within
terms of application licenses, too.

I might suggest psradm/psrset defaulting to persistent, but adding a
flag like -t (temporary) for one-off non-persistent use?

-Dan

Dan Foster wrote:
> In article <1144816749.555175.3780@u72g2000cwu.googlegroups.com>, bart.smaalders@gmail.com <bart.smaalders@gmail.com> wrote:
> 
>>Perhaps psrset and psradm should be persistent?
>>
>>What are your thoughts on that?
> 
> 
> I'd be in favor for this. We use this to put the processors into a
> specific and known state until otherwise needed in a different state.
> 
> E.g. we use it to take erroring processors offline to defer swapout to a
> less disruptive time or do other special performance-related tricks with
> psradm.
> 
> I can see how this might be used in certain situations to stay within
> terms of application licenses, too.
> 
> I might suggest psradm/psrset defaulting to persistent, but adding a
> flag like -t (temporary) for one-off non-persistent use?
> 
> -Dan


That -t (temporary) flag would break backward compatibility. Would it not be 
more sensible to have a -p (permanent) flag and keep the default as it is? That 
preserves backward compatibility.

You could always write your own startup script that does this.

-- 
Dave K     MCSE.

MCSE = Minefield Consultant and Solitaire Expert.

Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.

On 2006-04-11, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> Ceri Davies <ceri_usenet@submonkey.net> writes:
>> On 2006-04-11, Ceri Davies <ceri_usenet@submonkey.net> wrote:
>>> I have marked a number of CPUs in a machine no-intr using psradm.
>>> I can't see that this has changed anything on disk anywhere, so I am
>>> slightly worried that this change will not persist across a reboot.
>>>
>>> Will it?  I am running Solaris 10, and the manuals are drawing a blank.
>>
>> The answer to that question is "no".
>>
>>> If not, is there a canonical place to put this initialisation?
>>
>> Still open!
>
> Hi Ceri :-)))

Small world :)

> I'm not sure about a "canonical" place, but an /etc/init.d script that
> runs before important stuff fire up (i.e. network interfaces) seems ok.
>
> If you feel funky, an SMF service somewhere after milestone/single-user
> would be nice too.

That's cool.  So long as there is no /etc/psrset.conf or similar.  Not
that there's any reason that there should be, but you never know!

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere

On Thu, 13 Apr 2006 18:03:05 GMT,
Ceri Davies <ceri_usenet@submonkey.net> wrote:
>On 2006-04-11, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>> I'm not sure about a "canonical" place, but an /etc/init.d
>> script that runs before important stuff fire up (i.e. network
>> interfaces) seems ok.
>>
>> If you feel funky, an SMF service somewhere after
>> milestone/single-user would be nice too.
>
> That's cool.  So long as there is no /etc/psrset.conf or
> similar.  Not that there's any reason that there should be, but
> you never know!

None that I know of.  I usually set things up in an init.d script
of my own, saved in `/etc/init.d/processor', which is symlinked
from `/etc/rc1.d/S20psrctl' or similar :)

On 2006-04-11, Ceri Davies <ceri_usenet@submonkey.net> wrote:
> On 2006-04-11, Ceri Davies <ceri_usenet@submonkey.net> wrote:
>> I have marked a number of CPUs in a machine no-intr using psradm.
>> I can't see that this has changed anything on disk anywhere, so I am
>> slightly worried that this change will not persist across a reboot.
>>
>> Will it?  I am running Solaris 10, and the manuals are drawing a blank.
>
> The answer to that question is "no".
>
>> If not, is there a canonical place to put this initialisation?
>
> Still open!

OK, I've found this.

If you enable pools:

	pooladm -e

then default everything and persist the configuration to
/etc/pooladm.conf:

	pooladm -x
	pooladm -s

you can then ignore the big warning at the top of pooladm.conf, edit the
cpu.status of the CPUs that you want to change, and then load
pooladm.conf back in with:

	pooladm -c

This will be persistent.

There is apparently some way to do it with poolcfg, but I simply cannot
understand how to modify a "component" from the manpage.

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere

On 2006-04-21, Ceri Davies <ceri_usenet@submonkey.net> wrote:
> On 2006-04-11, Ceri Davies <ceri_usenet@submonkey.net> wrote:
>> On 2006-04-11, Ceri Davies <ceri_usenet@submonkey.net> wrote:
>>> I have marked a number of CPUs in a machine no-intr using psradm.
>>> I can't see that this has changed anything on disk anywhere, so I am
>>> slightly worried that this change will not persist across a reboot.
>>>
>>> Will it?  I am running Solaris 10, and the manuals are drawing a blank.
>>
>> The answer to that question is "no".
>>
>>> If not, is there a canonical place to put this initialisation?
>>
>> Still open!
>
> OK, I've found this.
>
> If you enable pools:
>
> 	pooladm -e
>
> then default everything and persist the configuration to
> /etc/pooladm.conf:
>
> 	pooladm -x
> 	pooladm -s
>
> you can then ignore the big warning at the top of pooladm.conf, edit the
> cpu.status of the CPUs that you want to change, and then load
> pooladm.conf back in with:
>
> 	pooladm -c
>
> This will be persistent.
>
> There is apparently some way to do it with poolcfg, but I simply cannot
> understand how to modify a "component" from the manpage.

That process is actually somewhat more stupid than it needs to be, but
it wasn't the only stupid thing I did yesterday afternoon so I'm just
putting it down to Friday.

The easy way to do it is to make your changes with psradm:

	psradm -i 1-3 5-7 9-11 13-15 17-19 21-23 25-27 29-31

Then, enable pools and just write out the config to disk:

	pooladm -e
	pooladm -s

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere