4017 – Kernel should be able to log additional events to scheduling history

PCR 4017 - Kernel should be able to log additional events to scheduling history

Summary: Kernel should be able to log additional events to scheduling history

Status:	ASSIGNED

Alias:	None

Product:	Kernel
Classification:	Deos
Component:	Kernel (show other PCRs)
Version:	Agave
Hardware:	All Deos

Priority:	Any Upcoming
Severity:	Enhancement
Target Milestone:	mainline
Assignee:	.Kernel

URL:
Whiteboard:

Duplicates (1):	A-142 (view as PCR list)
Depends on:
Blocks:

Reported:	2006-08-17 07:52 MST by dennis.irwin
Modified:	2024-12-11 13:05 MST (History)
CC List:	3 users (show)

See Also:
Impact Assessment:	---
Organization:	DDC-I, Inc.

Flags:	deosbugs.ccb: Requirements? deosbugs.ccb: Code? deosbugs.ccb: TestCases? deosbugs.ccb: TestProcedures? deosbugs.ccb: Other?

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this PCR.

Description dennis.irwin 2006-08-17 07:52:55 MST

In order to provide a better understanding of dynamic system behavior for both timing and sequence related analysis, additional events should be optionally logged into the system's scheduling history. One of the key types of event to log would be the traps into the kernel to access kernel services. Of particular interest would be the services that can cause a thread to give up the processor, such as the thread coordination services for mutex, event, and semaphore calls.

One possible implementation that has been suggested (by Ryan) is adding one level of indirection in the service vector table, which is indexed by KID. This would make two copies of the table available; one whould be for normal operation and the other the case where system service call logging has been enabled. Under normal conditions, where system service call logging is not enabled, the only increase in processing time for a system call over what is currently implemented would be the time to load the pointer to the service vector table.

An outstanding question is whether or not to log all system calls, to log a subset based on calls to an extension to the API for Status Monitor Support Services, of a predetermined subset of system service calls, such as those mentioned above. Logging all system calls may be excessive both in terms of CPU overhead and rate of data insertion into the log, which could make it difficult to retrieve the logged information quickly enough. Allowing dynamic selection of event to be logged may add more complexity than it is worth and could allow the same problem just described for logging all of the events. But, trying to pick a fixed subset may lead to a couple of other problems. First, it is still possible that there would be situations where the subset is still large enough to cause the problems described for the other two options. Second, it may be difficult to select the "correct" subset to cover all situations of interest. My initial feeling on this is that the API extension to selectively enable/disable event logging is the best compromise, assuming that the details of such an implementation are not too complex.

Comment 1 rroffelsen 2006-08-17 09:07:06 MST

Now that I think about it some more, there is no need to have the additional level of indirection.  We could have 1 table and the have the entries modified on the fly.

One question/concern I have is about performance.  If any thread is allowed to do this to any trapping API I think that constitute a time partitioning violation.  Perhaps this could only be done with debug services honored.

Perhaps a solution is to log an even each time the CPU is relinquished.  We could have a different event for reason (i.e. resource wait, mutex insufficient budget, etc...).

Comment 2 alarson 2006-08-17 10:41:05 MST

Or, don't do it in the kernel at all.  Have a tool/library that causes all references to kernel entrypoints redirected to a separate library that forwards the calls to the kernel.  Said library could then log the data in whatever fashion is appropriate.  This would make such logging process specific and obviate any time partitioning issues.

If we had argv/argc support, you could do it all via registry hacks by having the library be the main entrypoint for the process, then have it update the "real" executable prior to executing it.

Obviously not well baked yet, but an idea none the less.

Comment 3 deosbugs.ccb 2010-09-30 14:51:27 MST

CCB 2 visited this PCR on 2010-09-30.

Comment 4 deosbugs.ccb 2010-12-17 10:17:22 MST

CCB visited this PCR on 2010-12-17.

Comment 5 deosbugs.ccb 2011-03-07 15:55:50 MST

*** PCR 142 has been marked as a duplicate of this PCR. ***

Comment 6 deosbugs.ccb 2011-03-07 17:39:03 MST

CCB visited this PCR on 2011-03-07

Comment 7 deosbugs.ccb 2011-04-11 14:37:36 MST

CCB visited this PCR on 2011-04-11

Comment 8 deosbugs.ccb 2011-05-16 15:20:12 MST

CCB2 visited this PCR on 2011-05-16

Comment 9 deosbugs.ccb 2011-08-17 15:10:33 MST

CCB visited this PCR on 2011-08-17

Comment 10 deosbugs.ccb 2011-11-04 15:52:21 MST

CCB 2 visited this PCR on 2011-11-04

Comment 11 deosbugs.ccb 2012-01-31 13:45:25 MST

CCB visited this PCR on 2012-01-31

Comment 12 deosbugs.ccb 2012-05-15 08:40:15 MST

CCB visited this PCR on 2012-05-15

Comment 13 deosbugs.ccb 2012-06-08 13:16:42 MST

CCB 2 visited this PCR on 2012-06-08

Comment 14 deosbugs.ccb 2012-08-24 09:17:40 MST

CCB visited this PCR on 2012-08-24

Comment 15 deosbugs.ccb 2012-09-07 10:38:24 MST

CCB visited this PCR on 2012-09-07

Comment 16 rroffelsen 2012-09-17 16:00:32 MST

CCB visited this PCR on 2012-09-17

Comment 17 deosbugs.ccb 2012-11-19 12:19:33 MST

CCB visited this PCR on 2012-11-19

Comment 18 deosbugs.ccb 2012-11-26 17:45:52 MST

CCB visited this PCR on 2012-11-26

Comment 19 deosbugs.ccb 2013-02-12 21:17:26 MST

CCB visited this PCR on 2013-02-12

Comment 20 deosbugs.ccb 2013-03-18 14:35:18 MST

CCB visited this PCR on 2013-03-18

Comment 21 deosbugs.ccb 2013-05-15 10:12:05 MST

CCB visited this PCR on 2013-05-15

Comment 22 deosbugs.ccb 2013-07-19 11:25:54 MST

CCB visited this PCR on 2013-07-19

Comment 23 deosbugs.ccb 2013-11-15 17:40:09 MST

CCB visited this PCR on 2013-11-15

Comment 24 deosbugs.ccb 2014-05-20 10:14:05 MST

CCB 2 visited this PCR on 2014-05-20

Comment 25 deosbugs.ccb 2014-07-14 15:11:47 MST

CCB visited this PCR on 2014-07-14

Comment 26 deosbugs.ccb 2014-11-11 13:16:45 MST

CCB 2 visited this PCR on 2014-11-11

Comment 27 deosbugs.ccb 2014-11-17 08:57:54 MST

CCB visited this PCR on 2014-11-17

Comment 28 deosbugs.ccb 2016-04-18 12:56:25 MST

CCB visited this PCR on 2016-04-18

Comment 29 deosbugs.ccb 2016-06-20 13:09:19 MST

CCB visited this PCR on 2016-06-20

Comment 30 deosbugs.ccb 2017-02-01 09:36:33 MST

CCB visited this PCR on 2017-02-01-59501

Comment 31 deosbugs.ccb 2017-06-28 12:59:46 MST

CCB visited this PCR on 2017-06-28-69227

Comment 32 deosbugs.ccb 2021-03-26 09:34:24 MST

CCB visited this PCR on 2021-03-26-57787

Comment 33 deosbugs.ccb 2021-04-05 09:51:48 MST

CCB visited this PCR on 2021-04-05-59141

Comment 34 deosbugs.ccb 2023-08-14 11:04:59 MST

CCB visited this PCR on 2023-08-14-64795

Comment 35 deosbugs.ccb 2023-08-14 12:17:05 MST

PCR being taken off HOLD for kismet.  Kernel team lead to determine the appropriate solution to update the kernel vs create a tool, etc.
Good topic for the 2023 mini Geekfest.

Comment 36 deosbugs.ccb 2024-08-30 06:55:52 MST

CCB visited this PCR on 2024-08-30-49739

Comment 37 deosbugs.ccb 2024-12-11 13:05:13 MST

CCB visited this PCR on 2024-12-11-68907