Re: mmap() versus read()

MOLNAR Ingo (mingo@chiara.csoma.elte.hu)
Tue, 10 Mar 1998 00:07:35 +0100 (CET)


On Mon, 9 Mar 1998, Perry Harrington wrote:

> > > I think everyone will
> > > agree that the current clone() method of creating threads is costly
> > > at best. [...]
> >
> > uhm, ~20 usecs on a 200 MHz PPro, is that 'costly at best'?
>
> I still count in clock ticks. 35000 something IIRC last time I knew
> for a fork()/clone(). [...]

oops, it's more than 20 usecs, i accidentally have measured it on an SMP
system. On uniprocessors it's ~40 usecs on a 200 MHz PPro (should be
~11000 cycles on your box i think).

Thats not very cheap, but if you look at the clone() path, almost all of
the overhead comes from arch/i386/kernel/process.c:copy_thread(). You wont
get around that function no matter what threading abstraction you use,
unless you sacrifice some features.

[The function is not quite lightweight, but it could be improved: eg. the
clearing of the IO bitmap could be delayed until the first ioperm() call
by setting p->tss.bitmap outside of the TSS segment]

i've attached the code that does the clone() latency measurement.

-- mingo

--------------=>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <sys/wait.h>
#include <linux/unistd.h>

static unsigned int t1,t2,t3;

#define CYCLES(x) __asm__ __volatile__ ("rdtsc" :"=a" (x)::"edx")

void start_thread(void)
{
void **newstack = (void **) ((char *)malloc(1000) + 1000);

CYCLES(t1);
__asm__ __volatile__(
"int $0x80 \n\t" /* Linux/i386 system call */
"testl %0,%0 \n\t" /* check return value */
"jne 1f \n\t" /* jump if parent */
"call *%2 \n\t" /* start subthread function */
"movl %1,%0 \n\t"
"int $0x80 \n\t" /* exit system call: exit subthread */
"1: \n\t"
: :"a" (__NR_clone),"i" (__NR_exit), "r" (&&thread),
"b" (0xff00 | SIGCHLD), "c" (newstack));
CYCLES(t2);
return;

thread:
CYCLES(t3);
}

void main()
{
unsigned int i, min=-1;

for (i=0; i<100; i++) {
start_thread();
if (t2-t1 < min)
min = t2-t1;
wait(0);
}

printf("best clone() latency: %u cycles\n", min);
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu