health-check: An automated performance reporting tool

This new target will generated a bootable image that will compute some
system tests to estimate it's efficiency and health status.

A series of raw numbers will be generated and reported inside an
extended hw.py file.

This patch add the required makefile targets, the testing suite (make
health-check).

health-check is today only reporting the cpu performance by using
sysbench.

A typical output is like the following:
('cpu', 'physical_0', 'physid', '1'),
('cpu', 'physical_0', 'cores', '2'),
('cpu', 'physical_0', 'enabled_cores', '2'),
('cpu', 'physical_0', 'threads', '4'),
('cpu', 'physical', 'number', 1),
('cpu', 'logical', 'number', '4'),
('cpu', 'logical_0', 'bogomips', '5187.90'),
('cpu', 'logical_0', 'cache_size', '3072KB'),
('cpu', 'logical_0', 'loops_per_sec', 561),
('cpu', 'logical_1', 'bogomips', '5187.90'),
('cpu', 'logical_1', 'cache_size', '3072KB'),
('cpu', 'logical_1', 'loops_per_sec', 561),
('cpu', 'logical_2', 'bogomips', '5187.90'),
('cpu', 'logical_2', 'cache_size', '3072KB'),
('cpu', 'logical_2', 'loops_per_sec', 553),
('cpu', 'logical_3', 'bogomips', '5187.90'),
('cpu', 'logical_3', 'cache_size', '3072KB'),
('cpu', 'logical_3', 'loops_per_sec', 542),
('cpu', 'logical', 'loops_per_sec', 1604)]

Reporting is spliting physical cpu (sockets) and logical one (thoses
seen by Linux).

Detailed information about physical are only available if seen by lshw.
Bogomips & cache_size are taken from the /proc/cpuinfo while the
loops_per_sec are computed by running sysbench for 10 seconds.

Note that loops_per_sec are reported for
- each logical processor by running binding sysbench on the selected processor but also for
- all logical processors at one time by running sysbench with num-threads = the
  number of logical processors.
health-check: Adding memory performance report

This commit is using sysbench to analyze the performance of the memory
by checking several block size and from all the logical CPUs.

This could be useful to detect a processor that doesn't reach the memory at the proper speed.
NUMA systems could be affected by such behavior.

This component will help at discovering this effect.

A typical output is like :
 ('cpu', 'logical_0', 'bandwidth_1K', '3017'),
 ('cpu', 'logical_0', 'bandwidth_4K', '7037'),
 ('cpu', 'logical_0', 'bandwidth_1M', '10400'),
 ('cpu', 'logical_0', 'bandwidth_16M', '8859'),
 ('cpu', 'logical_0', 'bandwidth_128M', '9042'),
 ('cpu', 'logical_0', 'bandwidth_1G', '9012'),
 ('cpu', 'logical_1', 'bandwidth_1K', '2718'),
 ('cpu', 'logical_1', 'bandwidth_4K', '7048'),
 ('cpu', 'logical_1', 'bandwidth_1M', '10670'),
 ('cpu', 'logical_1', 'bandwidth_16M', '8764'),
 ('cpu', 'logical_1', 'bandwidth_128M', '8716'),
 ('cpu', 'logical_1', 'bandwidth_1G', '8987'),
 ('cpu', 'logical_2', 'bandwidth_1K', '3066'),
 ('cpu', 'logical_2', 'bandwidth_4K', '6913'),
 ('cpu', 'logical_2', 'bandwidth_1M', '10502'),
 ('cpu', 'logical_2', 'bandwidth_16M', '8884'),
 ('cpu', 'logical_2', 'bandwidth_128M', '8986'),
 ('cpu', 'logical_2', 'bandwidth_1G', '8853'),
 ('cpu', 'logical_3', 'bandwidth_1K', '3049'),
 ('cpu', 'logical_3', 'bandwidth_4K', '6969'),
 ('cpu', 'logical_3', 'bandwidth_1M', '10423'),
 ('cpu', 'logical_3', 'bandwidth_16M', '8878'),
 ('cpu', 'logical_3', 'bandwidth_128M', '8927'),
 ('cpu', 'logical_3', 'bandwidth_1G', '8663'),
 ('cpu', 'logical', 'bandwidth_1K', '3010'),
 ('cpu', 'logical', 'bandwidth_4K', '7000'),
 ('cpu', 'logical', 'bandwidth_1M', '10580'),
 ('cpu', 'logical', 'bandwidth_16M', '8704'),
 ('cpu', 'logical', 'bandwidth_128M', '8838'),
 ('cpu', 'logical', 'bandwidth_1G', '8941')
health-check: Adding missing file

Ooops.
health-check: Reporting DDR timings

As per some code from Cyring (http://code.cyring.fr/FTS/), it's possible
to get the DDR timing on some Intel processors.

This could be really useful to compare DDR timing from one node to
another to detect some different set of DDR memory banks.
health-check: Being verbose on stderr

By printing to stderr, it helps the main init to report the current
status while not flooding the resulting .py file.
health-check: Switching CPU benchmark to 5 seconds

5 seconds is enough to get a good overview of the CPU performance.
Dividing by 2 the time needed to get CPU perf makes the global process
faster.
health-check: Override the default resolv.conf

This is needed when moving your build machine from one network to
another.
health-check: Reporting DDR type

It could be DDR1,DDR2 or DDR3.

Could be useful to detect wrong setups.
detect.py: Adding disk's {vendor|model|rev}

This could be useful to filter the kind of storage device we shall play
with.
detect.py: Don't fail if not disk vendor information

Since last commit, we were failing if no disk's {vendor|model|rev} was
existing. That's pretty weird but when using virtualized devices, it
could happen.

Let's be safe on this topic, let's ignore if the file reading fails.
health-check: Reporting disk IOs performance

This patch add the ability to detect storage's performance by running
some fio patterns.

For a given test (4K read random or 1M read sequential), the test is
run of every disk in a standalone mode to detect the best of a device
without loading the system completly.

Then the test is run one more time on all detected's disks at the same
time to analyse how disks are performing when all the disks are
stressed. This could be useful to detect a controller not able to
substain the complete load
health-check: An automated performance reporting tool

This new target will generated a bootable image that will compute some
system tests to estimate it's efficiency and health status.

A series of raw numbers will be generated and reported inside an
extended hw.py file.

This patch add the required makefile targets, the testing suite (make
health-check).

health-check is today only reporting the cpu performance by using
sysbench.

A typical output is like the following:
('cpu', 'physical_0', 'physid', '1'),
('cpu', 'physical_0', 'cores', '2'),
('cpu', 'physical_0', 'enabled_cores', '2'),
('cpu', 'physical_0', 'threads', '4'),
('cpu', 'physical', 'number', 1),
('cpu', 'logical', 'number', '4'),
('cpu', 'logical_0', 'bogomips', '5187.90'),
('cpu', 'logical_0', 'cache_size', '3072KB'),
('cpu', 'logical_0', 'loops_per_sec', 561),
('cpu', 'logical_1', 'bogomips', '5187.90'),
('cpu', 'logical_1', 'cache_size', '3072KB'),
('cpu', 'logical_1', 'loops_per_sec', 561),
('cpu', 'logical_2', 'bogomips', '5187.90'),
('cpu', 'logical_2', 'cache_size', '3072KB'),
('cpu', 'logical_2', 'loops_per_sec', 553),
('cpu', 'logical_3', 'bogomips', '5187.90'),
('cpu', 'logical_3', 'cache_size', '3072KB'),
('cpu', 'logical_3', 'loops_per_sec', 542),
('cpu', 'logical', 'loops_per_sec', 1604)]

Reporting is spliting physical cpu (sockets) and logical one (thoses
seen by Linux).

Detailed information about physical are only available if seen by lshw.
Bogomips & cache_size are taken from the /proc/cpuinfo while the
loops_per_sec are computed by running sysbench for 10 seconds.

Note that loops_per_sec are reported for
- each logical processor by running binding sysbench on the selected processor but also for
- all logical processors at one time by running sysbench with num-threads = the
  number of logical processors.
health-check: Adding memory performance report

This commit is using sysbench to analyze the performance of the memory
by checking several block size and from all the logical CPUs.

This could be useful to detect a processor that doesn't reach the memory at the proper speed.
NUMA systems could be affected by such behavior.

This component will help at discovering this effect.

A typical output is like :
 ('cpu', 'logical_0', 'bandwidth_1K', '3017'),
 ('cpu', 'logical_0', 'bandwidth_4K', '7037'),
 ('cpu', 'logical_0', 'bandwidth_1M', '10400'),
 ('cpu', 'logical_0', 'bandwidth_16M', '8859'),
 ('cpu', 'logical_0', 'bandwidth_128M', '9042'),
 ('cpu', 'logical_0', 'bandwidth_1G', '9012'),
 ('cpu', 'logical_1', 'bandwidth_1K', '2718'),
 ('cpu', 'logical_1', 'bandwidth_4K', '7048'),
 ('cpu', 'logical_1', 'bandwidth_1M', '10670'),
 ('cpu', 'logical_1', 'bandwidth_16M', '8764'),
 ('cpu', 'logical_1', 'bandwidth_128M', '8716'),
 ('cpu', 'logical_1', 'bandwidth_1G', '8987'),
 ('cpu', 'logical_2', 'bandwidth_1K', '3066'),
 ('cpu', 'logical_2', 'bandwidth_4K', '6913'),
 ('cpu', 'logical_2', 'bandwidth_1M', '10502'),
 ('cpu', 'logical_2', 'bandwidth_16M', '8884'),
 ('cpu', 'logical_2', 'bandwidth_128M', '8986'),
 ('cpu', 'logical_2', 'bandwidth_1G', '8853'),
 ('cpu', 'logical_3', 'bandwidth_1K', '3049'),
 ('cpu', 'logical_3', 'bandwidth_4K', '6969'),
 ('cpu', 'logical_3', 'bandwidth_1M', '10423'),
 ('cpu', 'logical_3', 'bandwidth_16M', '8878'),
 ('cpu', 'logical_3', 'bandwidth_128M', '8927'),
 ('cpu', 'logical_3', 'bandwidth_1G', '8663'),
 ('cpu', 'logical', 'bandwidth_1K', '3010'),
 ('cpu', 'logical', 'bandwidth_4K', '7000'),
 ('cpu', 'logical', 'bandwidth_1M', '10580'),
 ('cpu', 'logical', 'bandwidth_16M', '8704'),
 ('cpu', 'logical', 'bandwidth_128M', '8838'),
 ('cpu', 'logical', 'bandwidth_1G', '8941')
health-check: Adding missing file

Ooops.
health-check: Reporting DDR timings

As per some code from Cyring (http://code.cyring.fr/FTS/), it's possible
to get the DDR timing on some Intel processors.

This could be really useful to compare DDR timing from one node to
another to detect some different set of DDR memory banks.
health-check: Being verbose on stderr

By printing to stderr, it helps the main init to report the current
status while not flooding the resulting .py file.
health-check: Switching CPU benchmark to 5 seconds

5 seconds is enough to get a good overview of the CPU performance.
Dividing by 2 the time needed to get CPU perf makes the global process
faster.
health-check: Override the default resolv.conf

This is needed when moving your build machine from one network to
another.
health-check: Reporting DDR type

It could be DDR1,DDR2 or DDR3.

Could be useful to detect wrong setups.
detect.py: Adding disk's {vendor|model|rev}

This could be useful to filter the kind of storage device we shall play
with.