Quote:
Originally Posted by bkk87
So, for an arbitrary thread (ignoring Java/JVM specifics) running on my linux system there is no system API I could use for determining the thread's I/O (disk) demand?
|
Correct - sortof.
Everyone in the discussion (you, me, the kernel, tool authors ...) need to have very precise definitions of what they want/provide. "the thread's I/O (disk) demand" for instance. I/O rate (per second - aka IOPS) ?, response time (per I/O) ?, average response time ?, delay time (per I/O), delay percentage, ... ?
Some of these are available, some require specific options at kernel compile time, some require inserting/activating probes into the running kernel functions.
Quote:
Do you mind giving me some hints how to research this topic further? You already mentioned the I/O scheduler. Maybe there is a way to approximate the I/O demands for each thread.
|
Historically Linux maintains stats in /proc - this is a virtual filesystem that exists in kernel cache, not disk. You read /proc/<whatever>, you get the current numbers, compare to your last read numbers and do the arithmetic. This is what most of the tools do for you. vmstat, top, whatever.
A while back taskstats was added to the kernel which does (some of) what the name implies. But all you get is averages, not exact per event durations. iotop is an example of a tool that exposes taskstats data and may give you enough. Your distro may or may not supply/support it as it requires said kernel options set. The Fedora devs didn't as they claimed they had measured too much overhead - which was bullsh1t. F22 appears to be the first to support it.
There is also a CPAN module to analyze taskstats data, but you need to get the data out first.