- Fix some more int-float conversion specifiers. - Max CPUs: increase to 16. - Scaling: adjust for scale_x/scale_y being floats. - nanosleep: capture errno if interrupted. - Fractional math - fix this up for 32bit systems. - Signals: HUP -> write graph and exit. - Allow fractional logging frequencies. - the e_fd variable was assumed to be static, otherwise you not only leak an fd per sample, but in theory it is garbage content as well - entropy: don't log this much debug output. - s/freq/hz/ - freq: test for freq==0 - entropy: log and graph the entropy_avail procfs file.
Apart from server systems, consumer HW is maxing at 12 cores right now, so, cap at 16.
Now that Hz can be very small, we want to reduce scale-x/y to sensible scales, otherwise the graphs get huge. This means setting scale-x to values < 1.0 - and thus float values. This touches on a ton of positioning references that need to convert from %i to %f.
If interrupted by a HUP signal, nanosleep will return EINTR and so we must capture this condition and terminate the mainloop, instead of errorring out.
On 32bit systems, long overflows during these calculations and causes nanosleep() to error out. Fix this up by simplifying the calculations and making sure we pass the parameters into the exact right type for nanosleep().
I'm removing the TERM/INT signal handling, as I want those to just terminate the application right away. HUP is a more suited signal name for tricking the logger into writing the graph out, so change the sighandler to that. Eventually, I want to add a USR1 handler that causes bootchart to plot and reset all it's data, but that's not a small patch.
This patch allows you to specify a float value for hz. The net effect is that you can increase the logging interval to values larger than 1.0 seconds, which is useful if you want to use the profiling code to profile a larger timeframe. I tested this with 0.1, 0.5, 22.5 values, and seems to work as expected.
…ak an fd per sample, but in theory it is garbage content as well
Probably don't need it, and we can invert the data back.
This would result in a floating point exception.
If we don't, we'll overwrite data at the array length, and a segfault happens at the last sample recording.
The allocation for the array ps_sched_sctruct in ps_struct is about 200k for MAXSAMPLES, but we most likely never will allocate anywhere near that much. Dynamically allocating this is a nice reduction in memory usage and memset() work.
The 'ps' data array used to be a flat, stack allocated array of 65k entries of each 200k each. This makes no sense anymore, and just puts us at the wrong end of VM tricks. Instead, we malloc() a per-process struct ps_struct of about 200k whenever needed. Because we now don't have a linear array anymore, we need to do pointer juggling to walk the entries as an array (->next_ps), and as a process tree (->childred, ->next). This makes walking and maintaining the tree of processes a bit more complex. All in all however the code cleans up a bit as we're now just walking linked lists, one way or another.
Signed-off-by: Koen Kooi <firstname.lastname@example.org>
…o a nice plot. This addition basically replaces Arjan van der Ven's 'bootgraph.pl' script which can be found in the scripts/ folder of the kernel sources. This implementation is highly simplified and intended to show the basic relations between kernel threads taking time to initialize. To enable the initcall graph, just add 'initcall_debug=1' on the kernel commandline additionally to the commandline code needed to start bootchartd.