Article View: comp.sys.transputer
Article #1058Re: Monitoring CPU Load?
From: Conor O'Neill
Date: Tue, 23 Oct 1990 13:33
Date: Tue, 23 Oct 1990 13:33
76 lines
2999 bytes
2999 bytes
>dario@techunix.BITNET (Dario Ringach) writes:
>
>
>>Is there any way to monitor the percent of usage of a
>>Transputer by running an OCCCAM process in PAR-rallel
>>with an application? Thanks. -Dario
Here is an example OCCAM process which can be executed at high priority.
It wakes up periodically, and detects whether a low priority process
was executing (and therefore was interrupted).
It updates an 'idle count', which can be communicated to another process.
PROC monitor(CHAN OF BOOL req, CHAN OF INT data)
VAL delay IS 1000 : -- 1 millisecond at high priority
INT Wdesc.save :
PLACE Wdesc.save AT 11 : -- address of saved low priority Wdesc
-- (see chapter 10.2 of the Compiler Writer's Guide)
BOOL running :
INT idle :
SEQ
idle := 0
running := TRUE
WHILE running
TIMER time :
INT now :
SEQ
time ? now
PRI ALT
BOOL request :
req ? request
IF
request -- if request is TRUE, return and reset the idle count
SEQ
data ! idle
idle := 0
TRUE -- if request is FALSE, shutdown
running := FALSE
time ? AFTER now PLUS delay
IF
Wdesc.save = ((MOSTNEG INT) + 1) -- '1' means low priority
idle := idle PLUS 1 -- make sure it can't overflow
TRUE
SKIP -- there was a low priority process executing
:
Sending TRUE down 'req' will return the idle count down 'data', and
reset the count. Sending FALSE will terminate the process.
The process would be used somewhat like this:
CHAN OF BOOL req :
CHAN OF INT data :
PRI PAR
monitor(req, data)
INT idle :
SEQ
... your program here
req ! TRUE
data ? idle
... display the idle count, or whatever
req ! FALSE
Note that the 'granularity' of the idle count can be adjusted by changing
the delay. While waiting on the timer queue, no CPU time is used, so the
only overhead is the cost of the loop every millisecond.
Note too that this process does not take other high priority processes
into account.
---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
Technical Details
Message-ID:
<12043@ganymede.inmos.co.uk>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!mcsun!ukc!inmos!conor@wren.inmos.co.ukReferences:
<9801@discus.technion.ac.il> <1990Oct17.110318.9927@specialix.co.uk>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!mcsun!ukc!inmos!conor@wren.inmos.co.uk From: conor@wren.inmos.co.uk (Conor O'Neill) Newsgroups: comp.sys.transputer Subject: Re: Monitoring CPU Load? Message-ID: <12043@ganymede.inmos.co.uk> Date: 23 Oct 90 13:33:05 GMT References: <9801@discus.technion.ac.il> <1990Oct17.110318.9927@specialix.co.uk> Sender: news@inmos.co.uk Reply-To: conor@inmos.co.uk (Conor O'Neill) Organization: INMOS Limited, Bristol, UK. Lines: 76