Hi Thomas,

On 3/23/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote:

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&#31967
http://www.opensolaris.org/jive/thread.jspa?messageID=85818&#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?


All  threads get switched  by calling switch() function., which further
calls disp() function to select the best next thread to executed. disp() is
the actual dispatcher and might return the idle thread for that processor
(each processor have its own idle thread created at booting time), if there
is no other suitable thread (read the dispatcher code) to execute. Switch
will always be called whenever the processor goes through context switch.

regards,
Gaurav


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




--
Gaurav
Email: [EMAIL PROTECTED]
--------------------------------------------
Read my articles at: http://lkdp.blogspot.com
--------------------------------------------
Easy to get air tickets at affordable price,
US to India Air Tickets: www.Ritz-Travel.com
Call at 001-503-848-2299 or mail at [EMAIL PROTECTED]
--------------------------------------------
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to