On Thu, 2005-03-03 at 14:51 +0300, Evgeniy Polyakov wrote:
> Simple program to test fork() performance.
...
In a bit more advanced version it checks for error value,
but it never happend.
It can also have more fine grained measurment,
but IMHO the picture is clear for small systems.
> Creating 10k forks 100 times.
> Results on 2-way SMP(1+1HT) Xeon for one fork()+exit():
>
> 2.6.11-rc4-mm1 494 usec
Actually sometimes it drops to 480 usecs.
> 2.6.11-rc4-mm1-fork-connector-no_userspace 509 usec
> 2.6.11-rc4-mm1-fork-connector-userspace 520 usec
>
> 5% fork() degradation(connector with userspace vs. vanilla) with fork()
> connector.
> On my test system global fork lock does not cost anything
> (tested both with and without userspace listener), but it is only
> 2-way(pseudo).
connector.c used in experiments is attached.
If fork connector analysis will show that global fork lock is a big
bottleneck,
than seq counter can be replaced with per-cpu counter, but then inner
header should
include cpu id to properly distinguish messages.
But it is totaly fork's connector area, so I will not break things.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
connector.c
Description: Text Data
signature.asc
Description: This is a digitally signed message part
|