Opened 14 years ago

Last modified 11 years ago

#404 new enhancement

IZ2193: Need more detailed built-in load values load sensors for operating system selection

Reported by: andreas Owned by:
Priority: normal Milestone:
Component: sge Version: 6.1
Severity: Keywords: execution


[Imported from gridengine issuezilla]

        Issue #:      2193             Platform:     All           Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      6.1              CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    pollinger (pollinger)
      QA Contact:     pollinger
       * Summary:     Need more detailed built-in load values load sensors for operating system selection
   Status whiteboard:

     Issue 2193 blocks:
   Votes for issue 2193:  1

   Opened: Fri Feb 16 05:43:00 -0700 2007 

In a heterogeneous Grid Engine cluster there is sometimes need to select queue
instances based on detailed information from uname -a about the operating
system. E.g. when I wish to run an application on a Solaris10 node I'd like to
the job like this

   -l os=solaris10

One can set-up a customized load sensor that reports the OS as a load value.

Add a new parameter to provide an easy and flexible means for getting the OS
reported. The attribute could allow information from
uname(2) 'struct utsname' be integrated into the load value. Setting the per
host parameter to


would then automatically give reasonable load sensor for all solaris machines.

The 'struct utsname' is supported by all POSIX OSes and is explained here


   ------- Additional comments from roland Wed Jun 25 01:40:14 -0700 2008 -------
We should add more new build in load values than just the OS. I can imagine to
report OS (SunOS or Linux), version (5 or 2), release (10 or 6).

Furthermore we should report not only num_proc but also cores per socket and
threads per CPU (primary interesting for Sun T1 Systems).

   ------- Additional comments from rayson Wed Jun 25 07:32:05 -0700 2008 -------
We discussed about collecting more kernel info before, See:

   ------- Additional comments from jeffbeadles Wed Jun 25 08:54:16 -0700 2008 -------
Please add the number of sockets in the system to this list -- SGE is currently
licensed per-socket, with no method of determine how many sockets are in the

Other things that we add and track as complexes and may be worth adding include;

cpubits - (32 or 64 typically)
cputype - (x86, x86-64, usparc, parisc, ipf, power, ...)

   ------- Additional comments from rayson Wed Jun 25 10:24:30 -0700 2008 -------
Docs on getting the number of sockets, cores, hardware threads, etc:

1) Multi-core and Linux Kernel
2) Detecting Multi-Core Processor Topology in an IA-32 Platform


Change History (0)

Note: See TracTickets for help on using tickets.