Currently async readahead is limited by following factors:

1) @ra_max_pages_per_file
2) @ra_max_read_ahead_whole_pages;
3) @ra_async_pages_per_file_threshold

If admin change a large value 4G to @ra_max_read_ahead_whole_pages,
with 16M RPC we could have 256 async readahead requests
flighting at the same time, this could consume all CPU
resources for readahead without limiting.

Even though we could set @max_active for workqueue,
RA requests still kept in the workqueue pool which help
prevent from CPU busying, the problem is RA still try to
use CPU later, we might still submit too many requests
to workqueue, so instead of limiting it in the workqueue,
we could limit it earlier, if there has been too many
async RA requests in the system(let's say default is 1/2
of CPU cores), we just fallback to sync RA, which limit
read threads using all CPU resources.

Change-Id: I370c04e014f24c795c1a28effca9c51b1db2a417
Signed-off-by: Wang Shilong <wshilong@ddn.com>
Reviewed-on: https://review.whamcloud.com/37927


Tested-by: jenkins <devops@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>