Re: AVL and hash in memory management

David S. Miller (davem@dm.cobaltmicro.com)
Sat, 19 Sep 1998 17:07:33 -0700


Date: Sun, 20 Sep 1998 12:01:12 +1200
From: Chris Wedgwood <chris@cybernet.co.nz>

On Fri, Sep 18, 1998 at 12:44:10PM -0700, David S. Miller wrote:

> The current fork+exit latency is humming close to ~200usec on the
> UltraSparc, every cycle counts at this point.

Just what applications _really_ need to fork that often, enough to
make this type of thing and issue?

The issue is not how often an application needs to fork.
The issue is that fork() and exit() are the bridges processes use to
get work done, so the sooner they can fork the sooner they can get to
the point where they can exec or do whatever and begin getting work
done.

Take a watch at the strace output for executing a configure script, or
what happens during a kernel build. You'll see. An even better thing
to watch is a glibc build, it's all about creating processes, redoing
their address spaces, doing work, and then destroying them.

Every time you type something, every time you run some script, every
time you start some build, every time a cron job starts, every time
blah blah blah, there's a bunch fork/exec/exit'ing going on. These
are the core operations of Unix to "do stuff", make the core
operations fast and at least as a basis your system begins to get
snappier and faster.

(BTW: when I did the bulk of the Ultra fork/exec/exit optimizations I
could notice with my eyes that glibc built faster than before, and
more scientific timing measurements later for glibc and kernel builds
supported this conjecture with facts)

Later,
David S. Miller
davem@dm.cobaltmicro.com

-
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/