Hi, I am working on a research project trying to integrate adaptive processor shutdown in the opensolaris kernel. We are currently looking into a simple strategy that takes a processor down when it becomes idle and wake it up when needed.
The modified kernel is imported in a full-system simulator Simics. We can communicate between the kernel and the simulator through register reads/writes and special magic instructions executed from the kernel to halt the simulator and read/write memory contents. We currently have modified the process dispatcher, so that it writes to a certain register when a processor enters the idle loop, and again when an idle processor needs to execute a task. By this we are able to track the processor transitions on a idle/not-idle level. However, we are also interested in the context switches between applications and when a certain process has terminated. My supervisor has posted two questions regarding this in the past: http://www.opensolaris.org/jive/thread.jspa?messageID=31967糟 http://www.opensolaris.org/jive/thread.jspa?messageID=85818𔼺 The second thread is mainly about userland, but I don't think this is the route we should go, due to the delay between kernel and userland. If we want to track precise information about shutdown of processors and the processes they run, I believe we should stay in the kernel. The first thread proposes looking at resume() in swtch.s. Is it correct that *all* context switches pass through these functions, either process->process, process->idle, and idle->process (albeit through _resume_from_idle()) ? What about interrupts? Looking through the code of resume, I have noticed the following interesting registers: %g7: current thread pointer %i0: new thread pointer (correct?) %i2: old proc pointer %i3: new proc pointer A strategy I had in mind then, was to have two places where the simulator would read these registers and extract the following fields: (referring to the line numbers in http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4/ml/swtch.s) 1. somewhere before line 175, read the contents of %g7 (thread_reg) to extract the current lwp id (field t_tid in thread.h) 2. somewhere after line 193, read the contents of %i0 to extract the lwp of the resuming thread, and read %i2 and %i3 to get the pid and process name from the current and resuming process. Do you think this strategy is correct? Do you have any other suggestions? Thanks, Thomas This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
