Wrap smp_processor_id in kpreempt_[dis|en]able

After surveying the code, the few places where smp_processor_id is used
were deemed to be safe to use with a preempt enabled kernel. As such, no
core logic had to be changed. These smp_processor_id call sites are simply
are wrapped in kpreempt_disable and kpreempt_enabled to prevent the
Linux kernel from emitting scary warnings.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Issue #83
Revert "Use SA_HDL_PRIVATE for SA xattrs"

This reverts commit ec2626ad3f695a2ced3946c4197ef64cbcac4959 which
caused consistency problems between the shared and private handles.
Reverting this change should resolve issues #709 and #727.  It
will also reintroduce an arc_anon memory leak which is addressed
by the next commit.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #709
Closes #727
Drop spill buffer reference

When calling sa_update() and friends it is possible that a spill
buffer will be needed to accomidate the update.  When this happens
a hold is taken on the new dbuf and that hold must be released
before calling dmu_tx_commit().  Failing to release the hold will
cause a copy of the dbuf to be made in dbuf_sync_leaf().  This is
done to ensure further updates to the dbuf never sneak in to the
syncing txg.

This could be left to the sa_update() caller.  But then the caller
would need to be aware of this internal SA implementation detail.
It is therefore preferable to handle this all internally in the
SA implementation.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #503
Closes #513
Revert Fix ASSERTION(!dsl_pool_sync_context(tx->tx_pool))

Commit eec8164771bee067c3cd55ed0a16dadeeba276de worked around an issue
involving direct reclaim through the use of PF_MEMALLOC.   Since we
are reworking thing to use KM_PUSHPAGE so that swap works, we revert
this patch in favor of the use of KM_PUSHPAGE in the affected areas.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #726
Revert Fix zpl_writepage() deadlock

The commit, cfc9a5c88f91f7b4d606fce89505e1f404691ea5, to fix deadlocks
in zpl_writepage() relied on PF_MEMALLOC.   That had the effect of
disabling the direct reclaim path on all allocations originating from
calls to this function, but it failed to address the actual cause of
those deadlocks.  This led to the same deadlocks being observed with
swap on zvols, but not with swap on the loop device, which exercises
this code.

The use of PF_MEMALLOC also had the side effect of permitting
allocations to be made from ZONE_DMA in instances that did not require
it.  This contributes to the possibility of panics caused by depletion
of pages from ZONE_DMA.

As such, we revert this patch in favor of a proper fix for both issues.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #726
Revert Disable direct reclaim for z_wr_* threads

This commit used PF_MEMALLOC to prevent a memory reclaim deadlock.
However, commit 49be0ccf1fdc2ce852271d4d2f8b7a9c2c4be6db eliminated
the invocation of __cv_init(), which was the cause of the deadlock.
PF_MEMALLOC has the side effect of permitting pages from ZONE_DMA
to be allocated.  The use of PF_MEMALLOC was found to cause stability
problems when doing swap on zvols. Since this technique is known to
cause problems and no longer fixes anything, we revert it.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #726
Fix znode corruption when using xattr=sa.

Using a separate SA handle (rather than zp->z_sa_hdl) to update
attributes corrupts the znode's mode flags (and possibly other
attributes as well).

This patch changes the zfs_sa_get_xattr/zfs_sa_set_xattr functions
so that they use zp->z_sa_hdl.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Adjust ARC settings

I made the following observations when examining arc_status from a
i386 system suffering from low performance and heavy idle load:

	- memory_throttle_count was extremely high
	- mru_evict_metadata and mru_ghost_evict_metadata were high
	- mfu_evict_data == 0
	- mfu_ghost_size == 0
	- mfu_ghost_evict_data == 0
	- mfu_ghost_evict_metadata == 0
	- arc_meta_used == arc_meta_max, but much less than arc_meta_limit
	- c_max == c
	- c_max >> arc_p_min_shift == c_min

Upon comparsion with an amd64 system, I noticed the following:

	- memory_throttle_count was low
	- mfu_evict_data, mfu_ghost_size, mfu_ghost_evict_data and
		  mfu_ghost_evict_metadata were all greater than zero
	- arc_meta_used < arc_meta_max < arc_meta_limit
	- c_max >> arc_p_min_shift > c_min
	- c_max > c

After looking at the code, I decided to make a few changes. First, I am
changing the minimum value of c_min to 16MB to mimic the change made in
freebsd/freebsd-head@8a78bd4cc19835b58ed1a8fbb45635a274dab8e9. Second, I
am changing the code to consider the minimum of both virtual memory and
physical memory when accepting changes to zfs_arc_max.

My hope is that changing the minimum value of c_min will correct some of
the inconsistencies between amd64 and i386 systems.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Linux 3.6-rc1 Compatibility: Use .mkdir instead of .create in 3.3 compatibility check

Linux 3.6 modifies inode_operations->create's function prototype. This
causes an autotools Linux 3.3. compatibility check for a function
prototype change in create, mkdir and mknode to fail. The check that
Since mkdir and mknode are unchanged, we modify the check to examine it
instead.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Remove autoconf check for CONFIG_PREEMPT

The autoconf macro which failed if CONFIG_PREEMPT was set in the kernel
config was removed. With the inclusion of a few previous patches
targeting support for preempt enabled kernels, it is now safe to run
with this kernel config option enabled.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Pre-allocate vdev I/O buffers

The vdev queue layer may require a small number of buffers
when attempting to create aggregate I/O requests.  Rather than
attempting to allocate them from the global zio buffers, which
is slow under memory pressure, it makes sense to pre-allocate
them because...

1) These buffers are short lived.  They are only required for
the life of a single I/O at which point they can be used by
the next I/O.

2) The maximum number of concurrent buffers needed by a vdev is
small.  It's roughly limited by the zfs_vdev_max_pending tunable
which defaults to 10.

By keeping a small list of these buffer per-vdev we can ensure
one is always available when we need it.  This significantly
reduces contention on the vq->vq_lock, because we no longer
need to perform a slow allocation under this lock.  This is
particularly important when memory is already low on the system.

It would probably be wise to extend the use of these buffers beyond
aggregate I/O and in to the raidz implementation.  The inability
to quickly allocate buffer for the parity stripes could result in
similiar problems.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Annotate KM_PUSHPAGE call paths with PF_NOFS

The txg_sync(), zfs_putpage(), zvol_write(), and zvol_discard()
call paths must only use KM_PUSHPAGE to avoid potential deadlocks
during direct reclaim.

This patch annotates these call paths so any accidental use of
KM_SLEEP will be quickly detected.   In the interest of stability
if debugging is disabled the offending allocation will have its
GFP flags automatically corrected.  When debugging is enabled
any misuse will be treated as a fatal error.

This patch is entirely for debugging.  We should be careful to
NOT become dependant on it fixing up the incorrect allocations.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
mzap_upgrade() must use kmem_alloc()

These allocations in mzap_update() used to be kmem_alloc() but
were changed to vmem_alloc() due to the size of the allocation.
However, since it turns out this function may be called in the
context of the txg_sync thread they must be changed back to use
a kmem_alloc() to ensure the KM_PUSHPAGE flag is honored.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Switch KM_SLEEP to KM_PUSHPAGE

Differences between how paging is done on Solaris and Linux can cause
deadlocks if KM_SLEEP is used in any the following contexts.

  * The txg_sync thread
  * The zvol write/discard threads
  * The zpl_putpage() VFS callback

This is because KM_SLEEP will allow for direct reclaim which may result
in the VM calling back in to the filesystem or block layer to write out
pages.  If a lock is held over this operation the potential exists to
deadlock the system.  To ensure forward progress all memory allocations
in these contexts must us KM_PUSHPAGE which disables performing any I/O
to accomplish the memory allocation.

Previously, this behavior was acheived by setting PF_MEMALLOC on the
thread.  However, that resulted in unexpected side effects such as the
exhaustion of pages in ZONE_DMA.  This approach touchs more of the zfs
code, but it is more consistent with the right way to handle these cases
under Linux.

This is patch lays the ground work for being able to safely revert the
following commits which used PF_MEMALLOC:

  21ade34 Disable direct reclaim for z_wr_* threads
  cfc9a5c Fix zpl_writepage() deadlock
  eec8164 Fix ASSERTION(!dsl_pool_sync_context(tx->tx_pool))

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #726