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.
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: [email protected] [email protected]
>
>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Quoting Cliff White <[email protected]>:
> >
> > 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
Quoting Con Kolivas <[email protected]>:
> 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
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
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
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/