1. 25 Dec, 2015 1 commit
  2. 26 Jul, 2013 1 commit
    • Tatyana Brokhman's avatar
      block: row: Remove warning massage from add_request · dbb41a09
      Tatyana Brokhman authored
      
      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: default avatarTatyana Brokhman <tlinder@codeaurora.org>
      dbb41a09
  3. 02 Jul, 2013 1 commit
    • Tatyana Brokhman's avatar
      block: row: change hrtimer_cancel to hrtimer_try_to_cancel · a1d6f9e5
      Tatyana Brokhman authored
      
      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: default avatarTatyana Brokhman <tlinder@codeaurora.org>
      a1d6f9e5
  4. 23 Jun, 2013 1 commit
    • Lee Susman's avatar
      block: row-iosched idling triggered by readahead pages · d2439090
      Lee Susman authored
      
      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: default avatarLee Susman <lsusman@codeaurora.org>
      d2439090
  5. 14 Apr, 2013 1 commit
  6. 21 Mar, 2013 2 commits
  7. 12 Mar, 2013 1 commit
    • Tatyana Brokhman's avatar
      block: row: Re-design urgent request notification mechanism · fe6fd2f8
      Tatyana Brokhman authored
      
      When ROW scheduler reports to the block layer that there is an urgent
      request pending, the device driver may decide to stop the transmission
      of the current request in order to handle the urgent one. This is done
      in order to reduce the latency of an urgent request. For example:
      long WRITE may be stopped to handle an urgent READ.
      
      This patch updates the ROW URGENT notification policy to apply with the
      below:
      
      - Don't notify URGENT if there is an un-completed URGENT request in driver
      - After notifying that URGENT request is present, the next request
        dispatched is the URGENT one.
      - At every given moment only 1 request can be marked as URGENT.
        Independent of it's location (driver or scheduler)
      
      Other changes to URGENT policy:
      - Only READ queues are allowed to notify of an URGENT request pending.
      
      CR fix:
      If a pending urgent request (A) gets merged with another request (B)
      A is removed from scheduler queue but is not removed from
      rd->pending_urgent_rq.
      
      CRs-Fixed: 453712
      Change-Id: I321e8cf58e12a05b82edd2a03f52fcce7bc9a900
      Signed-off-by: default avatarTatyana Brokhman <tlinder@codeaurora.org>
      fe6fd2f8
  8. 26 Feb, 2013 1 commit
  9. 21 Feb, 2013 1 commit
    • Tatyana Brokhman's avatar
      block: row: Re-design urgent request notification mechanism · 0c3b048d
      Tatyana Brokhman authored
      
      This patch updates the ROW URGENT notification policy to apply with the
      bellow:
      - Don't notify URGENT if there is an un-completed URGENT request in driver
      - After notifying that URGENT request is present, the next request
        dispatched is the URGENT one.
      - At every given moment only 1 request can be marked as URGENT.
        Independent of it's location (driver or scheduler)
      
      Other changes to URGENT policy:
      - Only queues that are allowed to notify of an URGENT request pending
      are READ queues
      
      Change-Id: I17ff73125bc7a760cea1116b466115a2df635a14
      Signed-off-by: default avatarTatyana Brokhman <tlinder@codeaurora.org>
      0c3b048d
  10. 14 Feb, 2013 4 commits
  11. 13 Jan, 2013 4 commits
  12. 20 Dec, 2012 1 commit
    • Tatyana Brokhman's avatar
      row: Add support for urgent request handling · 0ef81435
      Tatyana Brokhman authored
      
      This patch adds support for handling urgent requests.
      ROW queue can be marked as "urgent" so if it was un-served in last
      dispatch cycle and a request was added to it - it will trigger
      issuing an urgent-request-notification to the block device driver.
      The block device driver may choose at stop the transmission of current
      ongoing request to handle the urgent one. Foe example: long WRITE may
      be stopped to handle an urgent READ. This decreases READ latency.
      
      
      Change-Id: I84954c13f5e3b1b5caeadc9fe1f9aa21208cb35e
      Signed-off-by: default avatarTatyana Brokhman <tlinder@codeaurora.org>
      0ef81435
  13. 06 Dec, 2012 2 commits
  14. 15 Oct, 2012 2 commits
  15. 20 Sep, 2012 1 commit