block: ROW: squash commits [CAF]

3. block: row-iosched idling triggered by readahead pages

In the current implementation idling is triggered only by request

insertion frequency. This heuristic is not very accurate and may hit

random requests that shouldn't trigger idling. This patch uses the

PG_readahead flag in struct page's flags, which indicates that the page

is part of a readahead window, to start idling upon dispatch of a request

associated with a readahead page.

The above readehead flag is used together with the existing

insertion-frequency trigger. The frequency timer will catch read requests

which are not part of a readahead window, but are still part of a

sequential stream (and therefore dispatched in small time intervals).

Change-Id: Icb7145199c007408de3f267645ccb842e051fd00

Signed-off-by: Lee Susman <lsusman@codeaurora.org>

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Signed-off-by: Hieu Phan <aznrice2k4@gmail.com>

2. block: row: change hrtimer_cancel to hrtimer_try_to_cancel

Calling hrtimer_cancel with interrupts disabled can result in a livelock.

When flushing plug list in the block layer interrupts are disabled and an

hrtimer is used when adding requests from that plug list to the scheduler.

In this code flow, if the hrtimer (which is used for idling) is set, it's

being canceled by calling hrtimer_cancel. hrtimer_cancel will perform

the following in an endless loop:

1. try cancel the timer

2. if fails - rest_cpu

the cancellation can fail if the timer function already started. Since

interrupts are disabled it can never complete.

This patch reduced the number of times the hrtimer lock is taken while

interrupts are disabled by calling hrtimer_try_co_cancel. the later will

try to cancel the timer just once and return with an error code if fails.

CRs-fixed: 499887

Change-Id: I25f79c357426d72ad67c261ce7cb503ae97dc7b9

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Signed-off-by: Hieu Phan <aznrice2k4@gmail.com>

1. block: row: Remove warning massage from add_request

Regular priority queues is marked as starved if it skipped a dispatch due to being
 empty. When a new request is added to a starved queue it will be marked as
 urgent. The removed WARN_ON was warning about an impossible case when a regular priority (read) queue was marked as starved but wasn't empty. This is
 a possible case due to the bellow: If the device driver fetched a read
 request that is pending for transmission and an URGENT request arrives, the
 fetched read will be reinserted back to the scheduler. Its possible that the
 queue it will be reinserted to was marked as starved in the meanwhile due
 to being empty.

CRs-fixed: 517800

Change-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c

Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>