GitHub PushEvent at 2014-01-29 14:26:56
Repository: pf-kernel
Actor: mcdope
Payload: {"shas":[["a20e393e37410481b04591fd18397d5a3a153087","99f36c60c59139e87b7a4bb00825087a26736849@gmail.com","Manually merged `0001-block-cgroups-kconfig-build-bits-for-BFQ-v7-3.12.patch`\nSource: http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php","Tobias Bäumer",false],["4cd5653c84eb4f613bf4b2ecd5de5992ed5fa3e9","99f36c60c59139e87b7a4bb00825087a26736849@gmail.com","Manually merged `0002-block-introduce-the-BFQ-v7-I-O-sched-for-3.12.patch`\nSource: http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php","Tobias Bäumer",false],["1e7f803a2f4173f5a9c6e4df492796a6894127a3","ddd3503978591997e768ebc37fca6c687c31d545@unimore.it","block, bfq: add Early Queue Merge (EQM) to BFQ-v7 for 3.12.0\n\nA set of processes may happen  to  perform interleaved reads, i.e., requests\nwhose union would give rise to a  sequential read  pattern.  There are two\ntypical  cases: in the first  case,   processes  read  fixed-size chunks of\ndata at a fixed distance from each other, while in the second case processes\nmay read variable-size chunks at  variable distances. The latter case occurs\nfor  example with  KVM, which  splits the  I/O generated  by the  guest into\nmultiple chunks,  and lets these chunks  be served by a  pool of cooperating\nprocesses,  iteratively  assigning  the  next  chunk of  I/O  to  the first\navailable  process. CFQ  uses actual  queue merging  for the  first type  of\nrocesses, whereas it  uses preemption to get a sequential  read pattern out\nof the read requests  performed by the second type of  processes. In the end\nit uses  two different  mechanisms to  achieve the  same goal: boosting the\nthroughput with interleaved I/O.\n\nThis patch introduces  Early Queue Merge (EQM), a unified mechanism to get a\nsequential  read pattern  with both  types of  processes. The  main idea  is\nchecking newly arrived requests against the next request of the active queue\nboth in case of actual request insert and in case of request merge. By doing\nso, both the types of processes can be handled by just merging their queues.\nEQM is  then simpler and  more compact than the  pair of mechanisms used in\nCFQ.\n\nFinally, EQM  also preserves the  typical low-latency properties of BFQ, by\nproperly restoring the weight-raising state of  a queue when it gets back to\na non-merged state.\n\nSigned-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\nReviewed-by: Paolo Valente <paolo.valente@unimore.it>","Mauro Andreolini",false]],"size":3,"ref":"refs/heads/pf-3.12","head":"1e7f803a2f4173f5a9c6e4df492796a6894127a3"}