> On Thu, 2 Sep 1999, Vladimir Dergachev wrote:
>
> > Can someone more knowledgable than me tell of the current status of
> > threads in Linux on SMP and some history ?
> > In particular:
> > * can two threads from the same process run on two different cpus ?
>
> Simple answer: yes.
> Fuller answer: there is no such thing as "two threads from the same
> process". Under Linux, a thread is a process is a thread.
>
> Threads commonly share VM and open files, but they may share more or
> less, depending upon the application.
>
> Just as processes may run concurrently on different CPUs, so may threads,
> them beingf one and the same.
>
> > * what happens in event of cache thrashing ? Is there any code to
> > optimize for this situation ? (have no idea)
>
> Explain? There is code to keep the processes on the same CPU in
> some circumstances, but cache-thrashing is largely an application
> effect.
>
> If you have you hogs, battering away at the same buffer, then the
> bus could well get swamped.
>
> > * are threaded programs guaranteed not to run slower on SMP in
> > comparasion to UP systems ?
>
> You get no timing/scheduling guarantees - this is not an RTOS. You
> would be hard pushed to construct an example, but it's not impossible.
>
Not hard pushed at all. The problem is that both cpus have caches. So
suppose you have two static variables:
static char A;
static char B;
variable A is accessed often by thread 1, variable B is accessed often by
thread 2. (if you want something more tangible, imagine that each thread
is computing a checksum of it's own array and these variables keep the
result - this is just for the sake of the argument).
Now on UP system each thread will take approximately half the cycles
available. On SMP system threads will do same if scheduled to one cpu, but
will do considerably worse when scheduled to two different cpus.
As pointed by Mark Hans to me ia32 has 32byte cache lines. Thus if the
above example gets compiled so that variables A and B are further than 32
bytes apart all is ok and no perfomance loss is expected. However if they
are close (as they should be) each time the threads run on two different
cpus making you are limited to FSB speed.
Note that the same behaviour will happen even when variables are declared
long. I would also imagine that on a system with only one cpu-intensive
multi-threaded program running you'll get a slowdown as opposed to the
case when you start any other program that will take that cpu from you.
(say a while(1) loop).
> > * was this situation always this way (i.e. 2.0.*, 2.2.* and 2.3.*)
>
> Yes.
>
> > * is there any way for a process to request that it's threads should
> > run on the same cpu ?
>
> Processes don't have threads. They _are_ threads. (As far as the
> kernel is concerned - if your application or threads library likes
> to pretend that one process/thread/task is in charge, then it is more
> than welcome to do so.)
>
> That aside, there are patches which allow processes to request that
> they run on only a certain set of CPUs. You could use them, though
> really, it's the kernel's job to ensure that the application doesn't
> have to do things like this.
>
thank you
Vladimir Dergachev
> Matthew.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/