RE: Bug/limitation in 'time' (kernel setings?)...

[Bruce Dawson]

Note that the ~2ms/process create is when the power management fails to get
invoked. It drops to ~0.6ms/process create when the CPU ramps up to full
speed. The chart you list from twelve years ago shows 6.0 ms to spawn a new
process, so my machine is about ten times faster -- seems about right.
Cloning a process is not comparable because in my test the kernel has to
load and exec() expr, not just fork() bash.

> Right there, it shows you that the scheduler is taking almost 33% of your
time.

I don't follow your logic. How do you know that it is the scheduler? I can
see that when you run your schedtool script it shows 15% to 34.4% of CPU
time consumed. I say that the rest is process startup, you say scheduler.
I'm not sure what evidence points to the scheduler, and I'm not sure what
math you used to come up with the 33% figure. You'll have to elucidate.

> Then your kernel is misconfigured for your workload.

What? My kernel is executing the tasks fine. When my CPU runs at full speed
it is slightly faster than yours, and when it runs at 1/3 speed it is slower
than yours. In both cases 'time' reports that the CPU is not pegged when it
is. Our kernels are behaving quite similarly.

> What documentation would you have updated?

The bash documentation where it mentions the 'time' command, and the 'time'
documentation.

-----Original Message-----
From: Linda Walsh [mailto:bash@tlinx.org] 
Sent: Wednesday, March 20, 2013 1:12 AM
To: Bruce Dawson
Cc: bug-bash
Subject: Re: Bug/limitation in 'time' (kernel setings?)...



Bruce Dawson wrote:
> The reply below is way too long, but oh well.
> 
> The summary is:
> I am 100% certain that my ExprCount() loop is CPU bound.
----
        Your stats claim 530 iterations/second when spawning expr.

That's ~2ms/process create.

In an article from 14 years ago on a 200Mhz Pentium, Linux process creates
were ~1ms.

http://www.linuxjournal.com/article/2941
(table @
http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/029
/2941/2941f1.jpg)

If you believe that a modern processor running at 1.6GHz, takes twice as
long as a 14 year old pentium, then there is little likelihood that you will
be convinced by any logical argument.



You need to rebuild your kernel with the config option turned on -- in fact,
you need to build your own kernel if you want to do any sort of kernel
benchmarks.


> You seem convinced that the task is not CPU bound on my machine, but 
> I'm convinced that it is.
---
        Then your kernel is misconfigured for your workload.

You said:
> I am 100% certain that my ExprCount() loop is CPU bound. It is 
> unfortunate that time gives inaccurate information about this. It 
> would be nice if the documentation acknowledged that in order to save 
> future generations from confusion.
----
What documentation would you have updated?


Here is a perl program:
#!/usr/bin/perl
die "need count" unless @ARGV;
my $count=$ARGV[0];
my $counter=$count;
while ($counter-->0) {
  my $pid;
  if (my $pid=fork() ) {
    waitpid($pid,0);
  }else {
    exec "/bin/true"; # use 'exit(0)' to just time forks w/no image load
  }
}
-----------------------------
> /usr/bin/time /tmp/sp.pl 10000
 time schedtool -a 3 -e /tmp/sp.pl 10000 6.83sec 0.05usr 0.97sys (15.05%
cpu)
---
But if I don't confine it to 1 cpu:
> time /tmp/sp.pl 10000                  
10.54sec 0.20usr 2.59sys (26.52% cpu)

Just forks:
> time /tmp/sp.pl 10000
7.23sec 0.12usr 2.36sys (34.35% cpu)
> time /tmp/sp.pl 10000
7.21sec 0.12usr 2.35sys (34.39% cpu)
---
1cpu forks:

> time schedtool -a 3 -e /tmp/sp.pl 10000               
4.32sec 0.06usr 0.95sys (23.69% cpu)
Ishtar:law> time schedtool -a 3 -e /tmp/sp.pl 10000 4.29sec 0.05usr 0.96sys
(23.80% cpu)

-----------------

Right there, it shows you that the scheduler is taking almost 33% of your
time.

That may be cpu, but it is not cpu that your program is using.
That's why I say your accounting is off.







>From these figures, I would say it's closer to 1000/second