LU-1669 vvp: Use lockless __generic_file_aio_write

Testing multi-threaded single shard file write performance has shown the
inode mutex to be a limiting factor when using the generic_file_aio_write
function. To work around this bottle neck, this change replaces the
locked version of that call with the lock less version, specifically,
__generic_file_aio_write.

In order to maintain posix consistency, Lustre must now employ it's own
locking mechanism in the higher layers. Currently writes are protected
using the lli_write_mutex in the ll_inode_info structure. To protect
against simultaneous write and truncate operations, since we no longer
take the inode mutex during writes, we must down the lli_trunc_sem
semaphore.

Unfortunately, this change by itself does not garner any performance
benefits. Using FIO on a single machine with 32 GB of RAM, write
performance tests were ran with and without this change applied; the
results are below:

    +---------+-----------+---------+--------+--------+
    |     fio v2.0.13     |   Write Bandwidth (KB/s)  |
    +---------+-----------+---------+--------+--------+
    | # Tasks | GB / Task | Test 1  | Test 2 | Test 3 |
    +---------+-----------+---------+--------+--------+
    |    1    |    64     |  452446 | 454623 | 443070 |
    |    2    |    32     |  850318 | 565373 | 570233 |
    |    4    |    16     | 1058900 | 463546 | 482837 |
    |    8    |     8     | 1026300 | 468190 | 481119 |
    |   16    |     4     | 1065500 | 503160 | 550127 |
    |   32    |     2     | 1068600 | 462228 | 502873 |
    |   64    |     1     |  991830 | 556618 | 483634 |
    +---------+-----------+---------+--------+--------+

 * Test 1: Lustre client running 04ec54f. File per process write
           workload. This test was used as a baseline for what we
           _could_ achieve in the single shared file tests if the
           bottle necks were removed.

 * Test 2: Lustre client running 04ec54f. Single shared file
           workload, each task writing to a unique region.

 * Test 3: Lustre client running 04ec54f + this patch. Single shared
           file workload, each task writing to a unique region.

In order to garner any real performance benefits out of a single shared
file workload, the lli_write_mutex needs to be broken up into a range
lock. That would allow write operations to unique regions of a file to
be executed concurrently. This work is left to be done in a follow up
patch.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Change-Id: I0023132b5d941b3304f39f015f95106542998072
LU-1669 llite: Replace write mutex with range lock (WIP)

Testing has shown the ll_inode_inode's lli_write_mutex to be a limiting
factor with single shared file write performance, when using many
writing threads on a single machine. Even if each thread is writing to a
unique portion of the file, the lli_write_mutex will prevent no more
than a single thread to ever write to the file simultaneously.

This change attempts to remove this bottle neck, by replacing this mutex
with a range lock. This should allow multiple threads to write to a
single file simultaneously iff the threads are writing to unique regions
of the file.

NOTE: Performance testing hasn't been done on this version of the patch,
      so the below paragraph is merely expected behaviour based on prior
      results.

Unfortunately, performance tests do not show this patch to garner any
better write throughput when writing to a single file (using multiple
threads writing to unique file regions, of course). Instead, the
bottleneck simply shifts to the inode's i_mutex lock, which is used in
the generic_file_aio_write function (via lustre_generic_file_write).

Although this patch alone does not produce the desired performance
benefits for single shared file write workloads, it is a step in the
right direction. Now, more work is needed to address the bottleneck
surrounding the inode's i_mutex and the generic_file_aio_write call.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Change-Id: I71e060c190065d87a20dc8df3104f898883d0583