Add visibility into arc_read through a new kstat

[prakashsurya]

This change is an attempt to add visibility into the arc_read calls
occurring on a system, in real time. To do this, a list was added to the
in memory SPA data structure for a pool, with each element on the list
corresponding to a call to arc_read. These entries are then exported
through the kstat interface, which can then be interpreted in userspace.

For each arc_read call, the following information is exported:

• A unique identifier (uint64_t)
• The time the entry was added to the list (hrtime_t)
  (not wall clock time; relative to the other entries on the list)
• The objset ID (uint64_t)
• The object number (uint64_t)
• The indirection level (uint64_t)
• The block ID (uint64_t)
• The name of the function originating the arc_read call (char[24])
• The arc_flags from the arc_read call (uint32_t)

From this exported information one can see, in real time, exactly what
is being read, what function is generating the read, and whether or not
the read was found to be already cached.

There is still some work to be done, but this should serve as a good
starting point.

Specifically, dbuf_read's are not accounted for in the currently
exported information. Thus, a follow up patch should probably be added
to export these calls that never call into arc_read (they only hit the
dbuf hash table). In addition, it might be nice to create a utility
similar to "arcstat.py" to digest the exported information and display
it in a more readable format. Or perhaps, log the information and allow
for it to be "replayed" at a later time.

Signed-off-by: Prakash Surya [email protected]

[prakashsurya]

See also: openzfs/spl#288

[ColdCanuck]

How much does this add on the kernel's stack ?

I ask as I am perilously close to stack overflow at the best of times. When using ZFS in anger, the stack depth averages 5500, peaks regularly at 7000, on a 8192 stack. I have infrequent crashes with no logs which might be attributed to stack overflow. I would not view making ZFS more unstable to add a feature of limited utility to the majority of users as an improvement.

By all means add debugging, but please keep it out of the mainstream.

[behlendorf]

@ColdCanuck You raise a valid concern, we don't want to do anything which will destabilize the code. However, in this case there's virtually no impact on the stack so that shouldn't be a problem. We just wanted to get this posted for some initial review.

[prakashsurya]

Closing in favor of #1748