1) Why not use your 'null' program, which in your blog, you state makes little
difference.
2) Better, why not use the simple 'fork'/exit' which doesn't call a separate
program; (that's
one reason for switching to perl or better, would be C;
Note the perl prog:
#!/usr/bin/perl
die "need count" unless @ARGV;
my $count=$ARGV[0];
while ($count-- > 0) {
my $pid;
if (my $pid=fork()) { # if $pid is set, then it is the pid of a child
waitpid($pid,0); # so parent waits for child to finish before continuing
} else { # else we are in child (or fork failed);
# If fork failed prog will exit
exit 0; # if we are in child, immediately exit (no exec);
#exec "/bin/true"; # alternate test case to load a simple prog
}
}
schedtool is not a script -- it is system tool to control scheduler operations.
see also 'cpupower' to set/fix frequency and/or monitor idle-info
Note that in executing 'no program' (just doing a fork), but with the task
switching (scheduler activity), we get, at best ~ 35% cpu usage:
> time /tmp/sp.pl 10000
7.29sec 0.11usr 2.41sys (34.59% cpu)
Now change the perl program to do all the forks at once.
then wait for all of them at once.
(so the parent and child won't alternate in the scheduler).
program for that is:
#!/usr/bin/perl
die "need count" unless @ARGV;
my $count=$ARGV[0];
my $counter=$count;
while ($counter-->0) { fork() || exit(0); }
while (waitpid(-1,0)>0) {};
print "counter=$counter\n";
----
Note I print counter at the end to verify that it executed the full count
if it did, it will be at "-1";
Now note the run time and cpu usage:
> time /tmp/sp1.pl 10000
counter=-1
1.50sec 0.04usr 1.43sys (98.03% cpu)
Notice its about 1/5th the time. I still forked the same number of
processes, and still waited for all of them to exit, but this
one was done without invoking the scheduler each time through the loop.
The difference between the fork {wait/exit}
and the fork(all) wait(all); is
that the scheduler is not invoked each time through the loop.
Nearly 75-80% of the time is spent in the scheduler.
