Sponsored Content
Operating Systems Solaris Upgrade Solaris 8 to Solaris 10 Post 302237066 by frozentin on Wednesday 17th of September 2008 12:45:36 AM
Old 09-17-2008
Quote:
Originally Posted by incredible
You can't migrate directly from 8 to 10. Its very different. Have to migrate to 9 first , then to 10.
That, my friend, is absolutely NOT true. I have updated 10 servers in the last month or so using a home-grown procedure (scripted/developed by a colleague), and not one server has had any problem.
 

2 More Discussions You Might Find Interesting

1. Solaris

Solaris 9 to Solaris 10 upgrade on Sun Fire 3800

Hello there! I have Sun Fire 3800 with very old Solaris 9 and I need to perform upgrade to concurrent Solaris 10 version, preserving current OS configuration. I supose to make it using Live Upgrade, but according to Solaris Live Upgrade Software: Minimum Patch Requirements page, I need to... (5 Replies)
Discussion started by: Sapfeer
5 Replies

2. Solaris

Upgrade Solaris 11.1 to Solaris 11.2 beta?

Ive googled a bit, but could not find out how to upgrade to Solaris 11.2 beta, using the IPS package manager. Does anyone know how to do it? (4 Replies)
Discussion started by: kebabbert
4 Replies
numa_scheduling_groups(4)				     Kernel Interfaces Manual					 numa_scheduling_groups(4)

NAME
numa_scheduling_groups - Compaq Tru64 UNIX NUMA Scheduling Groups description (libnuma library) DESCRIPTION
Normally, the kernel scheduler attempts to distribute the workload evenly over the entire machine. When the system resources are evenly utilized, the machine is considered to be balanced. When balancing the workload, the scheduler operates in a context-free manner; that is, processes may be distributed to various CPUs, or other resources, without regard to their function or relationship to one another. In cer- tain cases, a user may wish to bundle a group of processes together so that they have equal access to the same system resources. For instance, cooperating processes that share the same physical memory may perform better if all of these processes execute on CPUs that are local to that memory. NUMA Scheduling Groups (NSG) cause the scheduler load-balancing system to treat all members of an NSG as a unit. If one process belonging to an NSG moves from one Resource Affinity Domain (RAD) to another, all other members of the NSG have to move with it. NSGs and their members have the following characteristics: The resource domain of the first process joining an NSG provides the initial resource domain location for that NSG, called the NSG home RAD. All other processes joining the NSG (through the nsg_attach_pid() func- tion) will be migrated to the NSG home RAD. If the joining process is not allowed to migrate, the nsg_attach_pid() function will fail. To support load balancing, an NSG is allowed to migrate to any RAD on the system if none of its members is bound to a specific resource (such as another RAD, CPU, and so on). An NSG member is allowed to attach to or bind to a resource only if no other members are bound to differ- ent resources. The entire NSG will migrate to the RAD containing the resource at the time it was successfully bound. If one NSG member is bound to a resource, all other members of that NSG are also bound to the RAD containing that resource, because the NSG and, therefore its members, is no longer allowed to migrate. SEE ALSO
Commands: runon(1) Functions: bind_to_cpu(3), nsg_attach_pid(3), nsg_detach_pid(3), nsg_destroy(3), nsg_get(3), nsg_get_pids(3), nsg_init(3), nsg_set(3), numa_intro(3), rad_attach_pid(3), rad_bind_pid(3), rad_detach_pid(3) numa_scheduling_groups(4)
All times are GMT -4. The time now is 11:54 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy