Re: Selecting target CPU for thread
Patricia Shanahan wrote:
Kenneth P. Turvey wrote:
On Mon, 28 Jan 2008 15:59:50 -0800, Todd wrote:
On Jan 28, 1:55 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
[Snip]
I am sorry that I was unclear - is there any way using Java to get the
cpu id for the current thread? if the answer is yes, how is it done?
The answer is no, not without native code. But the real answer is that
you don't need it. You should probably be using the id of the thread,
not
the CPU. This you can get.
I don't agree with "you don't need it".
Consider the following basic question: "Are threads moving around too
much?". There is a non-zero cost to moving a thread, because each
processor accumulates cache contents and other history for the threads
it is running. Excessive thread movement is a possible hypothesis if a
thread has an unexpectedly large cache miss rate. On the other hand, it
is also undesirable to leave an imbalance too long.
How would one investigate this sort of question without asking about
mappings between threads and processors?
From outside the JVM, by preference. On the inside, all
a thread could (perhaps) do is discover which CPU it was running
on a moment ago, and do this many times at various points in
its execution. You could get (at best) a histogram of the
number of times the thread found itself to have been on each
CPU; with considerable effort you might even extend this to
distinguish between "shortly after something that probably
blocked" (when a CPU switch may be relatively benign) and
"right in the middle of when I was doing something else" (when
a CPU switch might lead to the cache inefficiencies you mention).
But I don't see how the insider view can hope to spot all
the CPU changes, nor to relate even the observed changes to the
train of events that caused them. For that, you need a tool
that can see both the Java threads and the system scheduler at
the same time. On Solaris (or MacOS X or FreeBSD, I believe),
you'd naturally turn to DTrace. Other environments may not have
tools that are quite so useful, but can probably give summary
statistics (number of CPU migrations per second, that sort of
thing), even if unable to pin them down to specific threads.
I see little prospect of doing a good job of this as an
"inside job." In contrast to the all-too-common financial scams
we read about, this job cries out for "outsider information."
--
Eric Sosman
esosman@ieee-dot-org.invalid