Re: mmap() versus read()

Erik Corry (erik@arbat.com)
Tue, 10 Mar 1998 00:25:29 +0100 (MET)


In article <199803092146.NAA24273@sun4.apsoft.com> you wrote:
> > 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().

One of you is wrong. 20usecs is 4000 clock ticks.

> Context switches are somewhat costly from what I've heard too.

Much less costly between processes that share a memory
context, which they generally will if they are using posix
threads built on clone.

> Pardon me if I seem a little confrontational, I'm not the only one who
> sees clone() as costly.

The standard response it that you can pre-clone processes
and keep a cache of pre-cloned processes if you are
bothered by clone time. The other standard response is
that if you are worried about clone overhead because you
have 1000s of threads you are doing it wrong. (Just a quick
summary of what you would find if you searched Deja News.)

> Also, compare these to Solaris thread creation
> and such, you'll find that solaris can do some pretty good stuff on a
> lowly machine. (Perish the thought!)

The consesus on Linux has been to have only one class of
processes at the kernel level, and to optimise that one
class, rather than complicate everything by having first
and second class processes at the kernel level. You are
going to have a hard time changing that.

-- 
Erik Corry erik@arbat.com

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