1. 28 1月, 2008 4 次提交
    • J
      cfq-iosched: relax IOPRIO_CLASS_IDLE restrictions · 0871714e
      Jens Axboe 提交于
      Currently you must be root to set idle io prio class on a process. This
      is due to the fact that the idle class is implemented as a true idle
      class, meaning that it will not make progress if someone else is
      requesting disk access. Unfortunately this means that it opens DOS
      opportunities by locking down file system resources, hence it is root
      only at the moment.
      
      This patch relaxes the idle class a little, by removing the truly idle
      part (which entals a grace period with associated timer). The
      modifications make the idle class as close to zero impact as can be done
      while still guarenteeing progress. This means we can relax the root only
      criteria as well.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      0871714e
    • J
      block: cfq: make the io contect sharing lockless · 4ac845a2
      Jens Axboe 提交于
      The io context sharing introduced a per-ioc spinlock, that would protect
      the cfq io context lookup. That is a regression from the original, since
      we never needed any locking there because the ioc/cic were process private.
      
      The cic lookup is changed from an rbtree construct to a radix tree, which
      we can then use RCU to make the reader side lockless. That is the performance
      critical path, modifying the radix tree is only done on process creation
      (when that process first does IO, actually) and on process exit (if that
      process has done IO).
      
      As it so happens, radix trees are also much faster for this type of
      lookup where the key is a pointer. It's a very sparse tree.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      4ac845a2
    • N
      io_context sharing - cfq changes · 66dac98e
      Nikanth Karthikesan 提交于
      changes in the cfq for io_context sharing
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      66dac98e
    • J
      ioprio: move io priority from task_struct to io_context · fd0928df
      Jens Axboe 提交于
      This is where it belongs and then it doesn't take up space for a
      process that doesn't do IO.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      fd0928df
  2. 18 12月, 2007 1 次提交
  3. 07 11月, 2007 3 次提交
  4. 29 10月, 2007 2 次提交
  5. 24 7月, 2007 1 次提交
  6. 20 7月, 2007 2 次提交
    • A
      cfq: Write-only stuff in CFQ data structures · 8350163a
      Alexey Dobriyan 提交于
      There are some leftover bits from the task cooperator patch, that was
      yanked out again. While it will get reintroduced, no point in having
      this write-only stuff in the tree. So yank it.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      8350163a
    • V
      cfq: async queue allocation per priority · c2dea2d1
      Vasily Tarasov 提交于
      If we have two processes with different ioprio_class, but the same
      ioprio_data, their async requests will fall into the same queue. I guess
      such behavior is not expected, because it's not right to put real-time
      requests and best-effort requests in the same queue.
      
      The attached patch fixes the problem by introducing additional *cfqq
      fields on cfqd, pointing to per-(class,priority) async queues.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      c2dea2d1
  7. 18 7月, 2007 1 次提交
  8. 10 7月, 2007 1 次提交
    • J
      cfq-iosched: fix async queue behaviour · 15c31be4
      Jens Axboe 提交于
      With the cfq_queue hash removal, we inadvertently got rid of the
      async queue sharing. This was not intentional, in fact CFQ purposely
      shares the async queue per priority level to get good merging for
      async writes.
      
      So put some logic in cfq_get_queue() to track the shared queues.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      15c31be4
  9. 08 5月, 2007 1 次提交
  10. 30 4月, 2007 17 次提交
  11. 25 4月, 2007 1 次提交
    • J
      cfq-iosched: fix alias + front merge bug · 5044eed4
      Jens Axboe 提交于
      There's a really rare and obscure bug in CFQ, that causes a crash in
      cfq_dispatch_insert() due to rq == NULL.  One example of the resulting
      oops is seen here:
      
      	http://lkml.org/lkml/2007/4/15/41
      
      Neil correctly diagnosed the situation for how this can happen: if two
      concurrent requests with the exact same sector number (due to direct IO
      or aliasing between MD and the raw device access), the alias handling
      will add the request to the sortlist, but next_rq remains NULL.
      
      Read the more complete analysis at:
      
      	http://lkml.org/lkml/2007/4/25/57
      
      This looks like it requires md to trigger, even though it should
      potentially be possible to due with O_DIRECT (at least if you edit the
      kernel and doctor some of the unplug calls).
      
      The fix is to move the ->next_rq update to when we add a request to the
      rbtree. Then we remove the possibility for a request to exist in the
      rbtree code, but not have ->next_rq correctly updated.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5044eed4
  12. 21 4月, 2007 1 次提交
    • J
      cfq-iosched: fix sequential write regression · a9938006
      Jens Axboe 提交于
      We have a 10-15% performance regression for sequential writes on TCQ/NCQ
      enabled drives in 2.6.21-rcX after the CFQ update went in.  It has been
      reported by Valerie Clement <valerie.clement@bull.net> and the Intel
      testing folks.  The regression is because of CFQ's now more aggressive
      queue control, limiting the depth available to the device.
      
      This patches fixes that regression by allowing a greater depth when only
      one queue is busy.  It has been tested to not impact sync-vs-async
      workloads too much - we still do a lot better than 2.6.20.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9938006
  13. 12 2月, 2007 5 次提交