> Hi!
>
> > The way to handle this is to only have the idle process burn idle cycles
> > after a "start benchmark" system call, and then have it stop burning
> > idle cycles (and return the number burnt cycles :-) upon having received
> > a "end benchmark" system call.
> >
> > Having such a feature (even if it were an optional kernel patch) would
> > make it a *lot* easier to benchmark device drivers for CPU efficiency.
> > (Hint, hint, to potential budding kernel programmers out there --- this
> > would be a pretty good beginning-to-intermediate kernel hacking
> > project.)
>
> I think it is pretty well to do this in userland - as someone already
> shown... It is going to be precise unless you are _so_ tight on memory
> so that while(1) loop is swapped out...
another problem with a loop in userland is that you're influencing
the scheduler. that way you can't bench e.g. real network traffic
using userland networking programs (ftp, rsh, tcpspray).
having a counter in the _kernel_ idle process would fix this!
a raw 64bit counter should be enough, probably reported as
two unsigned 32bit values in /proc/idlecount or similar...
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/