Name | Last modified | Size | Description | |
---|---|---|---|---|
readme.txt | 2005-03-08 22:38 | 2.2K | ||
cpucycle.java | 2010-02-08 13:41 | 2.2K | ||
cpucycle-2.6.32.3.patch | 2010-02-08 09:55 | 5.7K | ||
cpucycle.2.6.10.patch | 2005-03-08 22:13 | 62K | ||
Hi, is just uploaded my developer snapshot to the sf-webserver: cpucycle.2.6.10.patch : apply on any recent linux kernel, you need to compile from scratch AFTER you have enabled cpucycle in character devices. cpucycle.java : simple test prog in java You wan to know, what this is: + This project provides a Linux 2.6 kernel patch that creates the + /dev/cpucycle devices that makes it possible from userspace to measure + the CPU-consumption (in CPU clock ticks!) in a scheduler aware + fashion. still there... so what's this good for? It's great for profiling! The cpycycle concept is tested on a single CPU machine provinding results (with cpucycle.java) with great precision. If you enable "Hyper Threading" (tm) these precision drops because the "instruction progess/clock tick" is not constant. The interface on /dev/cpucycle is simple, you can read 8 bytes (long long) of clock ticks consumed by this task (process or thread) beeing scheduled. If you write a (byte)1 the output of the filehandle changes to "network byte order" (nice in java). Reading/Writing is not buffered so you have to read all 8 bytes in one system call or the read will fail. But because of this it should be 100% thread safe. The code still needs work, right not it's in a "proof of concept" state. ToDo: - identify correct locking on task-structs - test on SMP machines (precision) - don't count IRQ-handlers (maybe also not system calls) - maybe add high precision System.currentTimeMilis in same call for fast profiling - identify potential on other architectures Feel free to mail me to my sf-address. Have fun - Leif snippet from the kernel docs: + You can compile the driver for /dev/cpucycle as a module but + you still need to recompile your kernel since it changes the + task_struct and add some code to schedule.c. + Automatic module loading is not supported by default, you need to + update your module-loading... + To get your /dev/cpucycle you still need to run: + mknod /dev/cpucycle c 10 137 ; chmod 666 /dev/cpucycle + (Note: the number 137 is not yet assigned officially, but + it was free when I last looked)