Replaced kmem_zalloc with kmem_cache_alloc in ddt.
Replaced kmem_zalloc with kmem_cache_alloc in arc.c. Added ddt_fini() method.
Set zfs_arc_min to 4MB

Decrease the mimimum ARC size from 1/32 of total system memory
(or 64MB) to a much smaller 4MB.

1) Large systems with over a 1TB of memory are being deployed
   and reserving 1/32 of this memory (32GB) as the mimimum
   requirement is overkill.

2) Tiny systems like the raspberry pi may only have 256MB of
   memory in which case 64MB is far too large.

The ARC should be reclaimable if the VFS determines it needs
the memory for some other purpose.  If you want to ensure the
ARC is never completely reclaimed due to memory pressure you
may still set a larger value with zfs_arc_min.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Fix l2arc_write_done/l2arc_evict race

A GPF may occur if an l2arc buffer is evicted before the write
completes for the l2arc buffer.  The l2arc_write_done() function
unconditionally starts walking the list at the write head so we
must verify that l2arc_evict() has not removed it from the list.

This long standing issue was exposed by allowing arc_adjust() to
evict entries from the l2arc due to memory pressue.  Prior to
this change buffers would only be evicted immediately in front
of the write hand or during l2arc cleanup.  In neither case could
we wrap around remove the write head as part of l2arc_evict().

PID: 3182   TASK: ffff88020df28080  CPU: 0   COMMAND: "z_null_int/0"
  [exception RIP: l2arc_write_done+128]
 6 [ffff880210e97c58] zio_done at ffffffffa0597e0c [zfs]
 7 [ffff880210e97cd8] zio_done at ffffffffa05982a7 [zfs]
 8 [ffff880210e97d58] zio_done at ffffffffa05982a7 [zfs]
 9 [ffff880210e97dd8] zio_execute at ffffffffa05948a3 [zfs]
10 [ffff880210e97e18] taskq_thread at ffffffffa041d8d8 [spl]
11 [ffff880210e97ee8] kthread at ffffffff81090d26
12 [ffff880210e97f48] kernel_thread at ffffffff8100c14a

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Redefine the arc_meta_used and arc_size values

The meaning of the arc_meta_used and arc_size values are ambiguous at
best. Prior to this change, the best definition I could come up with are
the following:

    * "arc_meta_used" is the sum of bonus buffers, dmu_buf_impl_t's,
      dnode_t's, arc headers, and arc buffers of type ARC_BUFC_METADATA

    * "arc_size" is the sum of arc_meta_used and arc buffers of type
      ARC_BUFC_DATA

With these two definitions in mind, their limits and associated logic for
eviction and arc tuning don't make a whole lot of sense; and here's why:

    1. First off, in the arc_adapt thread, we call arc_adjust_meta when
       arc_meta_used is greater than arc_meta_limit. The problem is that
       we evict buffer's of type ARC_BUFC_METADATA from the arc's mru
       and mfu before we every try to evict from the upper layers (via
       the prune callbacks). This can potentially lead us to evicting
       "hot" buffers from the mru and/or mfu while leaving "cold"
       dnode_t's, dmu_buf_impl_t's, etc. in the cache (consuming
       precious arc_meta_used space).

    2. Even though arc headers consume space within arc_meta_used, the
       ghost lists are never pruned based on arc_meta_limit. This can
       lead to a *very* unfortunate situation where the arc_met_used
       space is consumed entirely by "useless" arc headers (any new arc
       buffers of type ARC_BUFC_METADATA would almost immediately be
       evicted and placed on it's respective ghost list due to the
       arc_adapt thread calling arc_adjust_meta)

    3. The arc code appears to be littered these following assumptions:

           a) the size of the mfu is capped by arc_c - arc_p
           b) the sum of the mru and mfu sizes is capped by arc_c
           c) and finally, the sum of the mru and mfu sizes is arc_size

       The problem is, (c) is blatantly untrue (see previous definition
       above), which then invalidates the other assumptions as well.
       Using the proper definition of arc_size, we can arrive at the
       following truths:

           d) the arc_size is capped by arc_c
           e) the mru size is capped by arc_p
           f) the sum of arcstat_[data,other,hdr]_size is arc_size
           g) the sum of the mru and mfu sizes is arcstat_data_size
           h) which leads to, the sum of the mru and mfu sizes being
              capped by arc_c - arcstat_other_size - arcstat_hdr_size

       The unveiling of (h) means that, although unlikely, for certain
       values of arc_c, arcstat_other_size, and arcstat_hdr_size, one
       can completely starve the arc lists.

       The more likely scenario is not that *both* lists are starved
       simultaneously, it's that *one* list is starved for a certain
       time interval. For example, I've seen cases where the mru list
       grows to arc_p, and the mfu is squashed to a negligible size
       because it's space (the incorrectly assumed arc_c - arc_p space)
       is actually being consumed by arc header buffers, dnodes, etc.

As an attempt to remedy the situation, the meaning of the arc_meta_used
and arc_size values have been redefined as the following:

    * "arc_meta_used" is the sum of bonus buffers, and dmu_buf_impl_t's
      (i.e. arc_meta_used == arcstat_other_size)

    * "arc_size" is the sum of all arc buffers and arc headers
      (i.e. arc_size == arcstat_data_size + arcstat_hdr_size)

In addition, to directly address issues (1) and (2), we no longer prune
buffers of type ARC_BUFC_METADATA from the arc lists when over
arc_meta_limit. With the definition of arc_meta_used, that functionality
doesn't make sense (buffers residing in the arc lists no longer factor
into arc_meta_used.

Now, when over arc_meta_limit, we only call into the upper layers via
the prune callbacks. Ideally we would also reap from the kmem caches
for the objects which account for arc_meta_used (e.g. dnode_t,
dmu_buf_impl_t, etc.), but none of them have associated shrinkers.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Adjust arc_p based on "bytes" in arc_shrink

In an attempt to prevent arc_c from collapsing "too fast", the
arc_shrink() function was updated to take a "bytes" parameter by this
change:

    commit 302f753f1657c05a4287226eeda1f53ae431b8a7
    Author: Brian Behlendorf <behlendorf1@llnl.gov>
    Date:   Tue Mar 13 14:29:16 2012 -0700

        Integrate ARC more tightly with Linux

Unfortunately, that change failed to make a similar change to the way
that arc_p was updated. So, there still exists the possibility for arc_p
to collapse to near 0 when the kernel start calling the arc's shrinkers.

This change attempts to fix this, by decrementing arc_p by the "bytes"
parameter in the same way that arc_c is updated.

In addition, a minimum value of arc_p is attempted to be maintained,
similar to the way a minimum arc_p value is maintained in arc_adapt().

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Disable aggressive arc_p growth by default

For specific workloads consisting mainly of mfu data and new anon data
buffers, the aggressive growth of arc_p found in the arc_get_data_buf()
function can have detrimental effects on the mfu list size and ghost
list hit rate.

Running a workload consisting of two processes:

    * Process 1 is creating many small files
    * Process 2 is tar'ing a directory consisting of many small files

I've seen arc_p and the mru grow to their maximum size, while the mru
ghost list receives 100K times fewer hits than the mfu ghost list.

Ideally, as the mfu ghost list receives hits, arc_p should be driven
down and the size of the mfu should increase. Given the specific
workload I was testing with, the mfu list size should grow to a point
where almost no mfu ghost list hits would occur. Unfortunately, this
does not happen because the newly dirtied anon buffers constancy drive
arc_p to its maximum value and keep it there (effectively prioritizing
the mru list and starving the mfu list down to a negligible size).

The logic to increment arc_p from within the arc_get_data_buf() function
was introduced many years ago in this upstream commit:

    commit 641fbdae3a027d12b3c3dcd18927ccafae6d58bc
    Author: maybee <none@none>
    Date:   Wed Dec 20 15:46:12 2006 -0800

        6505658 target MRU size (arc.p) needs to be adjusted more aggressively

and since I don't fully understand the motivation for the change, I am
reluctant to completely remove it.

As a way to test out how it's removal might affect performance, I've
disabled that code by default, but left it tunable via a module option.
Thus, if its removal is found to be grossly detrimental for certain
workloads, it can be re-enabled on the fly, without a code change.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Revert "Return -1 from arc_shrinker_func()"

This reverts commit c11a12bc3b2e5ee9a6bd74e26f1a396b6025fbd4.

Out of memory events were fixed by reverting this patch.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
When at the limit, evict "data" before "metadata"

Work in progress. I will add a more detailed commit message soon.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Remove kmutex_t & kcondvar out of arc_buf_hdr_t

Under Linux these data types together consume around 100 bytes of space.
Having them in the arc_buf_hdr_t makes them nearly 50% larger than they
would be otherwise. When lock debugging is enabled it gets even larger.

This patch moves them to a single global array to be shared similar to
how the znode hold locks in zfs_sb work. We're trading some potential
for artificial lock contention for drastically smaller kernel memory
objects.
Fix the creation of ZPOOL_HIST_CMD pool history entries.

Move the libzfs_fini() after the zpool_log_history() call so the
ZPOOL_HIST_CMD entry can get written.

Fix the handling of saved_poolname in zfsdev_ioctl()
which was broken as part of the stack-reduction work in
a16878805388c4d96cb8a294de965071d138a47b.

Since ZoL destroys the TSD data in which the previously successful
ioctl()'s pool name is stored following every vop, the ZFS_IOC_LOG_HISTORY
ioctl has a very important restriction: it can only successfully write
a long entry following a successful ioctl() if no intervening vops have
been performed.  Some of zfs subcommands do perform intervening vops and
to do the logging themselves. At the moment, the "create" and "clone"
subcommands have been modified appropriately.
Add "zpool nagios" command

(Though incomplete this feature is working.)

The "zpool nagios" command behaves as a Nagios plugin - output a
single line of status information to stdout and exit with a status
code (0=OK, 1=Warning, 2=Critical, 3=Unknown).

There are a few cases that could use improvement for multi-pool
systems, and not all failure scenarios are tested, but it's
certainly a step in the right direction.

TODO:
* Specify pools which must be present on the system

* Deadman timer of sorts in case ioctls hang