Kernel Introspection:Design Meeting 2007-04-25#
Who#
bstecher, dbailey, adanko, cburgess
Summary#
What we did#
- more on pathnames
- more on api for the generic notifier
new questions#
- does the current notification scheme support cpu hog detection where the criteria is percentage cpu time averaged over some interval
- should we permit negative levels in thresholds (for the generality)
- an efficient means of notifying proccess creation is desireable: can we deliver the new pid to the client in their sigevent or must they poll.
- should we abandon notification thresholds entirely for cpu hog detection, given the difficulty/inefficiency of using thresholds designed for resource levels
- does /proc/allpids/notifier and /proc/anypid/notifier mean notify me on the set of current pids, or on the set of all pids including ones added in the future
- for thresholding /proc/allpids and /proc/anypid are distinct, are they distinct for bulk transfer?
- does a threshold triggers when the level is > its threshold or >= its threshold. (If the answer is >=, then we do need a signed threshold_level field in order to implement the "trigger on any change" functionality.
- /sumpids/ and /eachpid/ may be clearer than /allpids/ and /anypid/
More on pathnames #
- To the existing proc paths, like /proc/47821/ let's add /proc/47821/info, which when read returns the tagged process and thread structures, as we would return for bulk transfer, but just for that one process.
- lets use /proc/allpids/info to return tagged process and thread structures for all pids/tids in the system. i.e. bulk transfer
- lets use /notifier instead of /info (wherever /info is legal) to address the notifier device for the same information.
- for example. notification on a single process memory would be /proc/47821/notifier/memory_usage/
- notification of a threshold applied to each process, individually, would be: /proc/anypid/notifier/memory_usage
- notification of a threshold on the sum of memory used by all processes would be: /proc/allpids/notifier/memory_usage.
API for generic notifier#
This is the struct type seen by the user:
struct {
unint64 threshold_level;
sigevent users_event;
uint32 threshold_flags
}
THRESHOLD_FLAG_LEVEL 0x00000001 /* on: level detection, off: edge detection. recommended: off */
THRESHOLD_FLAG_UP 0x00000002 /* rising edge detect, or trigger above level */
THRESHOLD_FLAG_DOWN 0x00000004 /* falling edge detect, or trigger below level */
THRESHOLD_FLAG_ONESHOT 0x00000008 /* threshold self-deletes on being triggered */
This set of flags allows for these kinds of detections:
- trigger on the one alloc that exceeds a level: UP & NOT LEVEL
- tigger on the one dealloc that falls below a level: DOWN & NOT FLAG_LEVEL
- trigger on any change: FLAG_LEVEL & UP with threshold_level set to 0.
- trigger on every alloc/dealloc when above a level: FLAG_LEVEL & UP
- trigger on every alloc/dealloc when below a level: FLAG_LEVEL & DOWN
Using THRESHOLD_FLAG_LEVEL can cause a flood of sigevents, since it will trigger every time that resource's level changes. So THRESHOLD_FLAG_ONESHOT is offered as a throttling mechanism. It makes sure there is only one notification for each triggering event. (The user must re-create the threshold to re-arm.) With ONESHOT, during the time between triggering the threshold and the user recreating it, we will not be delivering sigenvents. This may be desirable to the user as a means of throttling notifications automatically to a level it can handle for those cases where the user is interested only in the final value of the resource. For other cases, using edge-detecting thresholds gives better throttling.
As an alternative throttling strategy, a user can define their sigevent to be a pulse, so repeating notifications, or a level sensitive threshold, will be compressed.