Linux SMT question
From: Michael Tewner
Date: Wed Dec 29 2004 - 05:42:35 EST
I'm sorry if this has been covered before. If it has, please direct me
on where to look.
Over the year, our university started acquiring dual Xeon servers. I
havn't been able to find consistent information regarding how linux
deals with the SMT (HT?). I have checked the source code, and am getting
a few hints, but perhaps someone could help me. People both in and out
of the university are asking me for help.
Our setup assumes a dual XEON HT IBM x335.
As far as I understand it, HT CPU's are 2 processing units sharing
memory; a forked process runs in parallel accessing the same text
segment, but each side maintiaining it's own Program Counter (and
registers?), etc. Is this correct?
Does this mean that if the scheduler puts different processes on the
same physical CPU they'll start context switching between them,
providing slower performance than had they been on 2 physical CPU's?
Some linux releases were showing 2 CPU's, while others were showing 4.
Was there a point where HT was incorporated in the kernel? And before
then, what did the scheduler do?
Are the following logs related to the SMT?
mapping CPU#0's runqueue to CPU#2's runqueue.
mapping CPU#1's runqueue to CPU#3's runqueue.
What (where?) does the scheduler do to run processes on separate
physical CPUs. I seem to remember hearing something about allocating a
process to separate physical CPU's BEFORE using logical CPU's but
something there doesn't sound right... I mean, if 5 processes are all
waiting, are 4 going to be allocated (2 on each CPU) or would only 2 be
allocated unless there are forked processes (that can run together on 2
sibling logical CPU's). Can the scheduler know that 2 processes are related?
Finally, is there a way to force an application to run an separate
physical CPU's? Perhaps a MOSIX-like /proc interface (where each PID has
a special file with preferences such as keep-local)?
I'm sorry for all the questions. I havn't seen this covered in Kernel
Traffic. The only solid information I found was at
http://kerneltrap.org/node/391 where Ingo Molnar explains the
requirements. What *has* been implemented?
Please CC replies. (I'll eventually join the kernel list....)
Thank you very much for your help,
-tewner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/