Opened 17 years ago

Last modified 11 years ago

#204 new defect

IZ1303: cleanup profiling initialization and cleanup

Reported by: joga Owned by:
Priority: normal Milestone:
Component: sge Version: current
Severity: Keywords: cleanup


[Imported from gridengine issuezilla]

        Issue #:      1303             Platform:     All       Reporter: joga (joga)
       Component:     gridengine          OS:        All
     Subcomponent:    cleanup          Version:      current      CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    ernst (ernst)
      QA Contact:     ernst
       * Summary:     cleanup profiling initialization and cleanup
   Status whiteboard:

     Issue 1303 blocks:
   Votes for issue 1303:

   Opened: Wed Oct 20 06:33:00 -0700 2004 

The calls to sge_prof_setup has been added to
every main function, sge_prof_cleanup at every
program exit in all clients and daemons.

These function calls should better be done in a
central setup and cleanup function, e.g. sge_setup
and sge_exit.

   ------- Additional comments from sgrell Thu Oct 28 00:55:42 -0700 2004 -------
The profiling contains of two data structures. One contains thread
information and one profiling level information. Some information is
stored in the profiling level right now, which should be stored the
thread info structure. Example for that:
- profile start time
- profile is started
- profile ever started
- thread num
- prev. level

To store them thread global, the ALL_LEVELS level is missused for it.

There should be only one command to turn on and off the profiling.
There is no need to enable and disable it per level.


   ------- Additional comments from sgrell Fri Oct 29 04:19:34 -0700 2004 -------
The total line in the usage summary output contains more usage, than
the sum of the previous lines. It looks like it is summing up all
profiling levels and not only thos, which are printed.


   ------- Additional comments from templedf Tue Nov 16 06:37:19 -0700 2004 -------
DRMAA encounters the maximum thread SegFault.  Profiling either needs
to support a dynamic number of threads, or it must able to be
centrally turned off for all threads at all levels.  Also, it's
*REALLY* ugly that I get a SegFault instead of some kind of warning or
error message or even abort!

   ------- Additional comments from templedf Tue Mar 29 03:13:21 -0700 2005 -------
I have done a lot of cleanup in the profiling library, including adding a master
shutoff switch.  See Issue 1471.

Change History (0)

Note: See TracTickets for help on using tickets.