[BENCHMARK] fork_load module tested for contest

[BENCHMARK] fork_load module tested for contest

[Con Kolivas]

I've been trialling a new load module for the contest benchmark
(http://contest.kolivas.net) which simply forks a process that does nothing,
waits for it to die, then repeats. Here are the results I have obtained so far:

noload:
Kernel                  Time            CPU             Ratio
2.4.19                  72.90           99%             1.00
2.4.19-ck7              71.55           100%            0.98
2.5.38                  73.86           99%             1.01
2.5.38-mm2              73.93           99%             1.01

fork_load:
Kernel                  Time            CPU             Ratio
2.4.19                  100.05          69%             1.37
2.4.19-ck7              74.65           95%             1.02
2.5.38                  77.35           95%             1.06
2.5.38-mm2              76.99           95%             1.06

ck7 uses O1, preempt, low latency
Preempt=N for all other kernels

Clearly you can see the 2.5 kernels have a substantial lead over the current
stable kernel.

This load module is not part of the contest package yet. I could certainly
change it to fork n processes but I'm not really sure just how many n should be.

Comments?

Con Kolivas

P.S. Results have negligible differences on repeat testing.

Re: [BENCHMARK] fork_load module tested for contest

[Rik van Riel]

On Thu, 26 Sep 2002, Con Kolivas wrote:

> I've been trialling a new load module for the contest benchmark
> (http://contest.kolivas.net) which simply forks a process that does
> nothing, waits for it to die, then repeats. Here are the results I have
> obtained so far:

> fork_load:
> Kernel                  Time            CPU             Ratio
> 2.4.19                  100.05          69%             1.37
> 2.4.19-ck7              74.65           95%             1.02
> 2.5.38                  77.35           95%             1.06
> 2.5.38-mm2              76.99           95%             1.06
>
> ck7 uses O1, preempt, low latency

Looks like the O(1) scheduler has a problem, then.  The continuous
fork() loop should get 20% of the CPU, not 5%.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org

Re: [BENCHMARK] fork_load module tested for contest

[Cliff White]

> 
> 
> I've been trialling a new load module for the contest benchmark
> (http://contest.kolivas.net) which simply forks a process that does nothing,
> waits for it to die, then repeats. Here are the results I have obtained so far:
> 
> noload:
> Kernel                  Time            CPU             Ratio
> 2.4.19                  72.90           99%             1.00
> 2.4.19-ck7              71.55           100%            0.98
> 2.5.38                  73.86           99%             1.01
> 2.5.38-mm2              73.93           99%             1.01
> 
> fork_load:
> Kernel                  Time            CPU             Ratio
> 2.4.19                  100.05          69%             1.37
> 2.4.19-ck7              74.65           95%             1.02
> 2.5.38                  77.35           95%             1.06
> 2.5.38-mm2              76.99           95%             1.06
> 
> ck7 uses O1, preempt, low latency
> Preempt=N for all other kernels
> 
> Clearly you can see the 2.5 kernels have a substantial lead over the current
> stable kernel.
> 
> This load module is not part of the contest package yet. I could certainly
> change it to fork n processes but I'm not really sure just how many n should be.

I think for OSDL/STP, it would be nice if n == number of CPU's, so maybe make 
'n' an arg?
When you say the process 'does nothing', what do you mean? It forks, then the 
child does exit() ?
cliffw
> 
> Comments?
> 
> Con Kolivas
> 
> P.S. Results have negligible differences on repeat testing.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [BENCHMARK] fork_load module tested for contest

[Con Kolivas]

Quoting Cliff White <cliffw@osdl.org>:
> > 
> > I've been trialling a new load module for the contest benchmark
> > (http://contest.kolivas.net) which simply forks a process that does
> nothing,
> > waits for it to die, then repeats. Here are the results I have obtained so
> far:
> > 
> > noload:
> > Kernel                  Time            CPU             Ratio
> > 2.4.19                  72.90           99%             1.00
> > 2.4.19-ck7              71.55           100%            0.98
> > 2.5.38                  73.86           99%             1.01
> > 2.5.38-mm2              73.93           99%             1.01
> > 
> > fork_load:
> > Kernel                  Time            CPU             Ratio
> > 2.4.19                  100.05          69%             1.37
> > 2.4.19-ck7              74.65           95%             1.02
> > 2.5.38                  77.35           95%             1.06
> > 2.5.38-mm2              76.99           95%             1.06
> > 
> > ck7 uses O1, preempt, low latency
> > Preempt=N for all other kernels
> > 
> > Clearly you can see the 2.5 kernels have a substantial lead over the
> current
> > stable kernel.
> > 
> > This load module is not part of the contest package yet. I could
> certainly
> > change it to fork n processes but I'm not really sure just how many n
> should be.
> 
> I think for OSDL/STP, it would be nice if n == number of CPU's, so maybe make
> 
> 'n' an arg?

Ok. I was more interested to know if maybe thousands of processes or something
like that would be interesting.

> When you say the process 'does nothing', what do you mean? It forks, then the
> 
> child does exit() ?

Yes the child forked execs nil.c which is basically return 0

Con

Useful fork info? WAS Re: [BENCHMARK] fork_load module tested for contest

[Con Kolivas]

Quoting Con Kolivas <conman@kolivas.net>:

> I've been trialling a new load module for the contest benchmark
> (http://contest.kolivas.net) which simply forks a process that just exits
> waits for it to die, then repeats. Here are the results I have obtained so
> far:
> 

[...fresh results below...]

> ck7 uses O1, preempt, low latency
> Preempt=N for all other kernels
> 
> Clearly you can see the 2.5 kernels have a substantial lead over the
> current
> stable kernel.
> 
> This load module is not part of the contest package yet. I could certainly
> change it to fork n processes but I'm not really sure just how many n should
> be.


I have extra information from the trial of this module:

noload:
Kernel                  Time            CPU             Ratio
2.4.19                  72.90           99%             1.00
2.4.19-ck7              71.55           100%            0.98
2.5.38                  73.86           99%             1.01
2.5.38-mm2              73.93           99%             1.01

fork_load:
Kernel                  Time            CPU             Ratio
2.4.19                  97.11           67%             1.33
2.4.19-ck7              72.34           92%             0.99
2.5.38                  75.32           92%             1.03
2.5.38-mm2              74.99           92%             1.03

2.4.19: Children forked: 32750
2.4.19-ck7: Children forked: 6477
2.5.38: Children forked: 5545
2.5.38-mm2: Children forked: 5351

You can see clearly repeatedly forking a new process significantly slows down
compile time for 2.4.19 but not the O(1) based kernels. However, the number of
processes that are forked is significantly reduced.

Is this information useful? 

Con

Re: Useful fork info? WAS Re: [BENCHMARK] fork_load module tested for contest

[Ingo Molnar]

On Thu, 26 Sep 2002, Con Kolivas wrote:

> fork_load:
> Kernel                  Time            CPU             Ratio
> 2.4.19                  97.11           67%             1.33
> 2.4.19-ck7              72.34           92%             0.99
> 2.5.38                  75.32           92%             1.03
> 2.5.38-mm2              74.99           92%             1.03
> 
> 2.4.19: Children forked: 32750
> 2.4.19-ck7: Children forked: 6477
> 2.5.38: Children forked: 5545
> 2.5.38-mm2: Children forked: 5351
> 
> You can see clearly repeatedly forking a new process significantly slows
> down compile time for 2.4.19 but not the O(1) based kernels. However,
> the number of processes that are forked is significantly reduced.

shouldnt the CPU load be 100% for such a test? If it isnt then perhaps
some other thing factors in. VM load? And i dont understand how a faster
kernel forks less children in the end. Perhaps the test is hitting some
sort of resource limit which has a different default in 2.5?

	Ingo

Re: Useful fork info? WAS Re: [BENCHMARK] fork_load module tested for contest

[Rik van Riel]

On Thu, 26 Sep 2002, Ingo Molnar wrote:

> > fork_load:
> > Kernel                  Time            CPU             Ratio
> > 2.4.19                  97.11           67%             1.33
> > 2.4.19-ck7              72.34           92%             0.99
> > 2.5.38                  75.32           92%             1.03
> > 2.5.38-mm2              74.99           92%             1.03
>
> shouldnt the CPU load be 100% for such a test?

The total load, yes.  The CPU has one 'make -j4' on the kernel
source and one fork load.

What I don't understand is why the fork load only gets 8% of
the CPU, instead of the 20% that is its right...

regards,

Rik
-- 
A: No.
Q: Should I include quotations after my reply?

http://www.surriel.com/		http://distro.conectiva.com/

Re: Useful fork info? WAS Re: [BENCHMARK] fork_load module tested for contest

[William Lee Irwin III]

On Thu, Sep 26, 2002 at 12:57:16PM +1000, Con Kolivas wrote:
> fork_load:
> Kernel                  Time            CPU             Ratio
> 2.4.19                  97.11           67%             1.33
> 2.4.19-ck7              72.34           92%             0.99
> 2.5.38                  75.32           92%             1.03
> 2.5.38-mm2              74.99           92%             1.03
> 2.4.19: Children forked: 32750
> 2.4.19-ck7: Children forked: 6477
> 2.5.38: Children forked: 5545
> 2.5.38-mm2: Children forked: 5351
> You can see clearly repeatedly forking a new process significantly slows down
> compile time for 2.4.19 but not the O(1) based kernels. However, the number of
> processes that are forked is significantly reduced.
> Is this information useful? 

Well, it means something. I should point out that the cost of pagetable
copying is increased by pte-based reverse mapping, and your "children
forked" throughput results reflect this. It's a known issue, and AFAIK
regarded as a reasonable tradeoff.

Cheers,
Bill