Re: newly released clone() based pthreads package

Jochen Toppe (joot@vnet.ibm.com)
Wed, 24 Jul 1996 10:22:11 -0400 (EDT)

>
> On Mon, 22 Jul 1996 joot@vnet.ibm.com wrote:
> >
> > I haven't really looked into the kernel scheduler code, but was
> > wondering about ways to get rid of some of the extra overhead
> > incurred context switching between two clone() based threads of the
> > same process.
>
> Already done, actually. The overhead for context switching between
> threads is minimal: on the x86 this is handled by the hardware (no TLB
> flush when the page table pointers match), on other architectures (alpha,
> sparc), the context switch routines notice it automatically.
>
> The only thing that needs doing is to give some "bonus points" for the
> scheduling code to threads that share the same mm space, in order for the
> scheduler to know that it should prefer scheduling threads after each
> other because the switch is low-overhead. This is trivial to do, look at
> the "goodness()" function in kernel/sched.c, where it does something like
> this:
>
> /* .. and a slight advantage to the current process */
> if (p == prev)
> weight += 1;
>
> which should probably be
>
> /* .. and a slight advantage to same VM setup */
> if (p->mm == prev->mm)
> weight += 1;

Stephen Tweedie said exactly the same thing :)

> but I haven't actually tried that out..
>
> > There are probably some changes that could be made to the kernel to
> > lower the overhead of switching between two threads of the same
> > process. The one that I can think of is sharing of all thread invariant
> > task_struct data. When the clone() ( do_fork() ) routine is called
> > a new struct task_struct is allocated, and the clone()'ing process's
> > entire task_struct is copied.
>
> No. Only the per-thread data is copied, and the thread-invariant stuff is
> already shared. Look at the "struct mm_struct", "struct files_struct" and
> "struct signal_struct" etc pointers in the task structure. A clone() that
> shares those structures just increments a usage pointer instead of copying
> anything.

I had seen the "struct mm_struct", and the other structs that get pointed
to when the clone() is done, but I guess that since the task_struct was
rather large, and I don't really know what most of it is for, I thought
that there could be more done to optimize it for threads. I didn't
really know what, and really was only suggesting the possibility. I also
think that I assumed the linux context switch was expensive, because it's
expensive on some other systems.

Peeter

--
 Peeter Joot          TOROLAB(PJOOT)         joot@vnet.ibm.com
 IBM Canada           Tie Line 778-3186      Phone 416-448-3186