{"push_id":996620158,"size":23,"distinct_size":23,"ref":"refs/heads/cm-11.0","head":"c642fe7b3b5faded54d2b064e537dabfc1b2d753","before":"023e099d937e19386288e094e631c69d18c28254","commits":[{"sha":"5b151ff3f2f13b11d6c0d7693f56910f5de5555b","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"block: fiops read/write request scale\n\nread/write speed of Flash based storage usually is different. For example,\nin my SSD maxium thoughput of read is about 3 times faster than that of\nwrite. Add a scale to differenate read and write. Also add a tunable, so\nuser can assign different scale for read and write.\n\nBy default, the scale is 1:1, which means the scale is a noop.\n\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/5b151ff3f2f13b11d6c0d7693f56910f5de5555b"},{"sha":"84a23a90fb27c2458bb4c1c7096058296e437466","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"block: fiops sync/async scale\n\nCFQ gives 2.5 times more share to sync workload. This matches CFQ.\n\nNote this is different with the read/write scale. We have 3 types of\nrequests:\n1. read\n2. sync write\n3. write\nCFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2\nare usually different for flash based storage. So we have both sync/async\nand read/write scale here.\n\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/84a23a90fb27c2458bb4c1c7096058296e437466"},{"sha":"c7e575904701829473cb8151a1f19cfa29432e57","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"block: fiops add ioprio support\n\nAdd CFQ-like ioprio support. Priority A will get 20% more share than priority\nA+1, which matches CFQ.\n\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/c7e575904701829473cb8151a1f19cfa29432e57"},{"sha":"bff5c113186affea747b61c585b74b4986d448df","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"block: fiops preserve vios key for deep queue depth workload\n\nIf the task has running request, even it's added into service tree newly,\nwe preserve its vios key, so it will not lost its share. This should work\nfor task driving big queue depth. For single depth task, there is no approach\nto preserve its vios key.\n\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/bff5c113186affea747b61c585b74b4986d448df"},{"sha":"b9061bda59e486212581f9421585c9fc802e8f4e","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"block: fiops bias sync workload\n\nIf there are async requests running, delay async workload. Otherwise\nasync workload (usually very deep iodepth) will use all queue iodepth\nand later sync requests will get long delayed. The idea is from CFQ.\n\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/b9061bda59e486212581f9421585c9fc802e8f4e"},{"sha":"d47886752dd96b641e097791e3357e162b0c2b91","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"block: fiops add some trace information\n\nAdd some trace information, which is helpful when I do debugging.\n\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/d47886752dd96b641e097791e3357e162b0c2b91"},{"sha":"16877578e2f463e4c14715f3f24511adbd0e1794","author":{"email":"20b1b82ea87150022f6495522a9f5e355ea8b305@gmail.com","name":"Arianna Avanzini"},"message":"block: introduce the BFQ-v6r2 I/O sched for 3.4\n\nAdd the BFQ-v6r2 I/O scheduler to 3.4.\nThe general structure is borrowed from CFQ, as much code. A (bfq_)queue is\nassociated to each task doing I/O on a device, and each time a scheduling\ndecision has to be made a queue is selected and served until it expires.\n\n    - Slices are given in the service domain: tasks are assigned budgets,\n      measured in number of sectors. Once got the disk, a task must\n      however consume its assigned budget within a configurable maximum time\n      (by default, the maximum possible value of the budgets is automatically\n      computed to comply with this timeout). This allows the desired latency\n      vs \"throughput boosting\" tradeoff to be set.\n\n    - Budgets are scheduled according to a variant of WF2Q+, implemented\n      using an augmented rb-tree to take eligibility into account while\n      preserving an O(log N) overall complexity.\n\n    - A low-latency tunable is provided; if enabled, both interactive and soft\n      real-time applications are guaranteed very low latency.\n\n    - Latency guarantees are preserved also in presence of NCQ.\n\n    - Also with flash-based devices, a high throughput is achieved while\n      still preserving latency guarantees.\n\n    - Useful features borrowed from CFQ: cooperating-queues merging (with\n      some additional optimizations with respect to the original CFQ version),\n      static fallback queue for OOM.\n\n    - BFQ supports full hierarchical scheduling, exporting a cgroups\n      interface.  Each node has a full scheduler, so each group can\n      be assigned its own ioprio (mapped to a weight, see next point)\n      and an ioprio_class.\n\n    - If the cgroups interface is used, weights can be explictly assigned,\n      otherwise ioprio values are mapped to weights using the relation\n      weight = IOPRIO_BE_NR - ioprio.\n\n    - ioprio classes are served in strict priority order, i.e., lower\n      priority queues are not served as long as there are higher priority\n      queues.  Among queues in the same class the bandwidth is distributed\n      in proportion to the weight of each queue. A very thin extra bandwidth\n      is however guaranteed to the Idle class, to prevent it from starving.\n\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/16877578e2f463e4c14715f3f24511adbd0e1794"},{"sha":"fce6f518ec824d9a5e7742b23bdba8c54de3c9f3","author":{"email":"20b1b82ea87150022f6495522a9f5e355ea8b305@gmail.com","name":"Arianna Avanzini"},"message":"block, bfq: add Early Queue Merge (EQM) to BFQ-v6r2 for 3.4.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\nprocesses, 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>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/fce6f518ec824d9a5e7742b23bdba8c54de3c9f3"},{"sha":"511d6656cd18dafe7aee1521faeb7f7baf713cd3","author":{"email":"d30c9d46e775e6b1566b32a8fd202963436bb554@google.com","name":"Ashish Sharma"},"message":"block: bfq: Squashed update from BFQ-v6r2 to BFQ-v7r1\n\nChange-Id: I7498f1f60253b0631a0ce36e7c20d6ec4e1df8f5","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/511d6656cd18dafe7aee1521faeb7f7baf713cd3"},{"sha":"35b11e06495677708649c9c0a1c67f8553d9e934","author":{"email":"209ba179947c35aa8a2a46f4caa398fd10622190@gmail.com","name":"Arne Coucheron"},"message":"block: bfq: Squashed update from BFQ-v7r1 to BFQ-v7r2\n\nChange-Id: I90a2156ae874fed703aafa22b721f59a0db40c51","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/35b11e06495677708649c9c0a1c67f8553d9e934"},{"sha":"aa6fb86d5c3d0576be9584dd9533c51c271eacb0","author":{"email":"476dffcf5c0a93e8095824780cbfdd127dfe86c4@gmail.com","name":"neutrondev"},"message":"Need this for merges","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/aa6fb86d5c3d0576be9584dd9533c51c271eacb0"},{"sha":"bda53684403f2714a505f9717dde57452e957884","author":{"email":"476dffcf5c0a93e8095824780cbfdd127dfe86c4@gmail.com","name":"neutrondev"},"message":"Need to merge smth","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/bda53684403f2714a505f9717dde57452e957884"},{"sha":"897c51565789286d4a05a65e279d3017882f89e7","author":{"email":"209ba179947c35aa8a2a46f4caa398fd10622190@gmail.com","name":"Arne Coucheron"},"message":"block: bfq: Squashed update from BFQ-v7r2 to BFQ-v7r3\n\nChange-Id: Id0ef3399d83bf4fd407eff64e695a7a3ec059646","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/897c51565789286d4a05a65e279d3017882f89e7"},{"sha":"c815ddd51eb12eaeca34c5dede74dba7d23c7e51","author":{"email":"209ba179947c35aa8a2a46f4caa398fd10622190@gmail.com","name":"Arne Coucheron"},"message":"block: bfq: Squashed update from BFQ-v7r3 to BFQ-v7r4\n\nChange-Id: I0b88bf402da4c7f4d9363132e14c1b86fcc5d21c","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/c815ddd51eb12eaeca34c5dede74dba7d23c7e51"},{"sha":"5d5a8b4dffa321c6bc640cacc1328a68f2ab8b44","author":{"email":"209ba179947c35aa8a2a46f4caa398fd10622190@gmail.com","name":"Arne Coucheron"},"message":"block: bfq: Squashed update from BFQ-v7r4 to BFQ-v7r5\n\nChange-Id: I749ef141246db7020cec0b10d980ec854a572603","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/5d5a8b4dffa321c6bc640cacc1328a68f2ab8b44"},{"sha":"49772801ea692c781997a36222cd10960c34d4c1","author":{"email":"20b1b82ea87150022f6495522a9f5e355ea8b305@gmail.com","name":"Arianna Avanzini"},"message":"block: Switch from BFQ-v7r5 for 3.4.0 to BFQ-v7r6 for 3.4.0\n\n. IMPROVEMENT: Introduced a new mechanism that helps get the job done\n  more quickly for services and applications that create or reactivate\n  many parallel I/O-bound processes. Examples are systemd at boot, or\n  commands such as git grep.\n. CODE IMPROVEMENTS: Small code cleanups and improvements.\n\nChange-Id: I69d00ba360f3b93b25c9f5a722cfe6d8a0df943b\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/49772801ea692c781997a36222cd10960c34d4c1"},{"sha":"4d9119aa06e286ea6e23a512e8c035379669a4c5","author":{"email":"2926236e622576bb8c477b2124dcaa6daa55bbd7@gmail.com","name":"YoshiShaPow"},"message":"bfq: update to BFQ-v7r7","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/4d9119aa06e286ea6e23a512e8c035379669a4c5"},{"sha":"52f65dc7245de1dc3939221f651d9c3a2bd5b3f1","author":{"email":"476dffcf5c0a93e8095824780cbfdd127dfe86c4@gmail.com","name":"neutrondev"},"message":"Revert for Merge","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/52f65dc7245de1dc3939221f651d9c3a2bd5b3f1"},{"sha":"550281c0d8e24cd0097c6240761a52991662e418","author":{"email":"c7fa93ff364b50c0a977a853487528f982a1ac48@codeaurora.org","name":"Tatyana Brokhman"},"message":"block: Adding ROW scheduling algorithm\n\nThis patch adds the implementation of a new scheduling algorithm - ROW.\nThe policy of this algorithm is to prioritize READ requests over WRITE\nas much as possible without starving the WRITE requests.\n\nChange-Id: I4ed52ea21d43b0e7c0769b2599779a3d3869c519\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: ROW: Correct minimum values of ROW tunable parameters\n\nThe ROW scheduling algorithm exposes several tunable parameters.\nThis patch updates the minimum allowed values for those parameters.\n\nChange-Id: I5ec19d54b694e2e83ad5376bd99cc91f084967f5\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: ROW: Fix forced dispatch\n\nThis patch fixes forced dispatch in the ROW scheduling algorithm.\nWhen the dispatch function is called with the forced flag on, we\ncan't delay the dispatch of the requests that are in scheduler queues.\nThus, when dispatch is called with forced turned on, we need to cancel\nidling, or not to idle at all.\n\nChange-Id: I3aa0da33ad7b59c0731c696f1392b48525b52ddc\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: Add support for reinsert a dispatched req\n\nAdd support for reinserting a dispatched request back to the\nscheduler's internal data structures.\nThis capability is used by the device driver when it chooses to\ninterrupt the current request transmission and execute another (more\nurgent) pending request. For example: interrupting long write in order\nto handle pending read. The device driver re-inserts the\nremaining write request back to the scheduler, to be rescheduled\nfor transmission later on.\n\nAdd API for verifying whether the current scheduler\nsupports reinserting requests mechanism. If reinsert mechanism isn't\nsupported by the scheduler, this code path will never be activated.\n\nChange-Id: I5c982a66b651ebf544aae60063ac8a340d79e67f\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: Add API for urgent request handling\n\nThis patch add support in block & elevator layers for handling\nurgent requests. The decision if a request is urgent or not is taken\nby the scheduler. Urgent request notification is passed to the underlying\nblock device driver (eMMC for example). Block device driver may decide to\ninterrupt the currently running low priority request to serve the new\nurgent request. By doing so READ latency is greatly reduced in read&write\ncollision scenarios.\n\nNote that if the current scheduler doesn't implement the urgent request\nmechanism, this code path is never activated.\n\nChange-Id: I8aa74b9b45c0d3a2221bd4e82ea76eb4103e7cfa\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nrow: Adding support for reinsert already dispatched req\n\nAdd support for reinserting already dispatched request back to the\nschedulers internal data structures.\nThe request will be reinserted back to the queue (head) it was\ndispatched from as if it was never dispatched.\n\nChange-Id: I70954df300774409c25b5821465fb3aa33d8feb5\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock:row: fix idling mechanism in ROW\n\nThis patch addresses the following issues found in the ROW idling\nmechanism:\n1. Fix the delay passed to queue_delayed_work (pass actual delay\n   and not the time when to start the work)\n2. Change the idle time and the idling-trigger frequency to be\n   HZ dependent (instead of using msec_to_jiffies())\n3. Destroy idle_workqueue() in queue_exit\n\nChange-Id: If86513ad6b4be44fb7a860f29bd2127197d8d5bf\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\ncfq-iosched: Fix null pointer dereference\n\nNULL pointer dereference can happen in cfq_choose_cfqg()\nwhen there are no cfq groups to select other than the\ncurrent serving group. Prevent this by adding a NULL\ncheck before dereferencing.\n\nUnable to handle kernel NULL pointer dereference at virtual address\n[<c02502cc>] (cfq_dispatch_requests+0x368/0x8c0) from\n[<c0243f30>] (blk_peek_request+0x220/0x25c)\n[<c0243f30>] (blk_peek_request+0x220/0x25c) from\n[<c0243f74>] (blk_fetch_request+0x8/0x1c)\n[<c0243f74>] (blk_fetch_request+0x8/0x1c) from\n[<c041cedc>] (mmc_queue_thread+0x58/0x120)\n[<c041cedc>] (mmc_queue_thread+0x58/0x120) from\n[<c00ad310>] (kthread+0x84/0x90)\n[<c00ad310>] (kthread+0x84/0x90) from\n[<c000eeac>] (kernel_thread_exit+0x0/0x8)\n\nCRs-Fixed: 416466\nChange-Id: I1fab93a4334b53e1d7c5dcc8f93cff174bae0d5e\nSigned-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>\n\nrow: Add support for urgent request handling\n\nThis patch adds support for handling urgent requests.\nROW queue can be marked as \"urgent\" so if it was un-served in last\ndispatch cycle and a request was added to it - it will trigger\nissuing an urgent-request-notification to the block device driver.\nThe block device driver may choose at stop the transmission of current\nongoing request to handle the urgent one. Foe example: long WRITE may\nbe stopped to handle an urgent READ. This decreases READ latency.\n\nChange-Id: I84954c13f5e3b1b5caeadc9fe1f9aa21208cb35e\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Add some debug information on ROW queues\n\n1. Add a counter for number of requests on queue.\n2. Add function to print queues status (number requests\n   currently on queue and number of already dispatched requests\n   in current dispatch cycle).\n\nChange-Id: I1e98b9ca33853e6e6a8ddc53240f6cd6981e6024\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Insert dispatch_quantum into struct row_queue\n\nThere is really no point in keeping the dispatch quantum\nof a queue outside of it. By inserting it to the row_queue\nstructure we spare extra level in accessing it.\n\nChange-Id: Ic77571818b643e71f9aafbb2ca93d0a92158b199\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: fix sysfs functions - idle_time conversion\n\nidle_time was updated to be stored in msec instead of jiffies.\nSo there is no need to convert the value when reading from user or\ndisplaying the value to him.\n\nChange-Id: I58e074b204e90a90536d32199ac668112966e9cf\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Aggregate row_queue parameters to one structure\n\nEach ROW queues has several parameters which default values are defined\nin separate arrays. This patch aggregates all default values into one\narray.\nThe values in question are:\n - is idling enabled for the queue\n - queue quantum\n - can the queue notify on urgent request\n\nChange-Id: I3821b0a042542295069b340406a16b1000873ec6\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Dispatch requests according to their io-priority\n\nThis patch implements \"application-hints\" which is a way the issuing\napplication can notify the scheduler on the priority of its request.\nThis is done by setting the io-priority of the request.\nThis patch reuses an already existing mechanism of io-priorities developed\nfor CFQ. Please refer to kernel/Documentation/block/ioprio.txt for\nusage example and explanations.\n\nChange-Id: I228ec8e52161b424242bb7bb133418dc8b73925a\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Idling mechanism re-factoring\n\nAt the moment idling in ROW is implemented by delayed work that uses\njiffies granularity which is not very accurate. This patch replaces\ncurrent idling mechanism implementation with hrtime API, which gives\nnanosecond resolution (instead of jiffies).\n\nChange-Id: I86c7b1776d035e1d81571894b300228c8b8f2d92\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Don't notify URGENT if there are un-completed urgent req\n\nWhen ROW scheduler reports to the block layer that there is an urgent\nrequest pending, the device driver may decide to stop the transmission\nof the current request in order to handle the urgent one. If the current\ntransmitted request is an urgent request - we don't want it to be\nstopped.\nDue to the above ROW scheduler won't notify of an urgent request if\nthere are urgent requests in flight.\n\nChange-Id: I2fa186d911b908ec7611682b378b9cdc48637ac7\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Update initial values of ROW data structures\n\nThis patch sets the initial values of internal ROW\nparameters.\n\nChange-Id: I38132062a7fcbe2e58b9cc757e55caac64d013dc\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n[smuckle@codeaurora.org: ported from msm-3.7]\nSigned-off-by: Steve Muckle <smuckle@codeaurora.org>\n\nblock: add REQ_URGENT to request flags\n\nThis patch adds a new flag to be used in cmd_flags field of struct request\nfor marking request as urgent.\nUrgent request is the one that should be given priority currently handled\n(regular) request by the device driver. The decision of a request urgency\nis taken by the scheduler.\n\nChange-Id: Ic20470987ef23410f1d0324f96f00578f7df8717\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Re-design urgent request notification mechanism\n\nWhen ROW scheduler reports to the block layer that there is an urgent\nrequest pending, the device driver may decide to stop the transmission\nof the current request in order to handle the urgent one. This is done\nin order to reduce the latency of an urgent request. For example:\nlong WRITE may be stopped to handle an urgent READ.\n\nThis patch updates the ROW URGENT notification policy to apply with the\nbelow:\n\n- Don't notify URGENT if there is an un-completed URGENT request in driver\n- After notifying that URGENT request is present, the next request\n  dispatched is the URGENT one.\n- At every given moment only 1 request can be marked as URGENT.\n  Independent of it's location (driver or scheduler)\n\nOther changes to URGENT policy:\n- Only READ queues are allowed to notify of an URGENT request pending.\n\nCR fix:\nIf a pending urgent request (A) gets merged with another request (B)\nA is removed from scheduler queue but is not removed from\nrd->pending_urgent_rq.\n\nCRs-Fixed: 453712\nChange-Id: I321e8cf58e12a05b82edd2a03f52fcce7bc9a900\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: urgent request: remove unnecessary urgent marking\n\nAn urgent request is marked by the scheduler in rq->cmd_flags with the\nREQ_URGENT flag. There is no need to add an additional marking by\nthe block layer.\n\nChange-Id: I05d5e9539d2f6c1bfa80240b0671db197a5d3b3f\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Prevent starvation of regular priority by high priority\n\nAt the moment all REGULAR and LOW priority requests are starved as long as\nthere are HIGH priority requests to dispatch.\nThis patch prevents the above starvation by setting a starvation limit the\nREGULAR\\LOW priority requests can tolerate.\n\nChange-Id: Ibe24207982c2c55d75c0b0230f67e013d1106017\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Update sysfs functions\n\nAll ROW (time related) configurable parameters are stored in ms so there\nis no need to convert from/to ms when reading/updating them via sysfs.\n\nChange-Id: Ib6a1de54140b5d25696743da944c076dd6fc02ae\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: urgent request: Update dispatch_urgent in case of requeue/reinsert\n\nThe block layer implements a mechanism for verifying that the device\ndriver won't be notified of an URGENT request if there is already an\nURGENT request in flight. This is due to the fact that interrupting an\nURGENT request isn't efficient.\nThis patch fixes the above described mechanism in case the URGENT request\nwas returned back to the block layer from some reason: by requeue or\nreinsert.\n\nCRs-fixed: 473376, 473036, 471736\nChange-Id: Ie8b8208230a302d4526068531616984825f1050d\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: row: Fix starvation tolerance values\n\nThe current starvation tolerance values increase the boot time\nsince high priority SW requests are delayed by regular priority requests.\nIn order to overcome this, increase the starvation tolerance values.\n\nChange-Id: I9947fca9927cbd39a1d41d4bd87069df679d3103\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\nSigned-off-by: Maya Erez <merez@codeaurora.org>\n\nblock: urgent: Fix dispatching of URGENT mechanism\n\nThere are cases when blk_peek_request is called not from blk_fetch_request\nthus the URGENT request may be started but the flag q->dispatched_urgent is\nnot updated.\n\nChange-Id: I4fb588823f1b2949160cbd3907f4729767932e12\nCRs-fixed: 471736\nCRs-fixed: 473036\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\n\nblock: Remove \"requeuing urgent req\" error messages\n\nIt is possible for URGENT request to be requeued/reinserted if it was\nfetched during the creation of a packed list. This end case is rare and is\nnot handled at the moment.\nThis patch changes the messages notifying of the above to debug level\n(instead of error) in order to clear the dmesg log.\n\nChange-Id: Ie8bc067e61559a6f702077b95c5dbcc426404232\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/550281c0d8e24cd0097c6240761a52991662e418"},{"sha":"395958eec20ef261a6581a69402a406b15f7fd2b","author":{"email":"9ae2fff1e81f4043f3b3adb9ed5eedbbd34e3953@codeaurora.org","name":"Lee Susman"},"message":"block: row-iosched idling triggered by readahead pages\n\nIn the current implementation idling is triggered only by request\ninsertion frequency. This heuristic is not very accurate and may hit\nrandom requests that shouldn't trigger idling. This patch uses the\nPG_readahead flag in struct page's flags, which indicates that the page\nis part of a readahead window, to start idling upon dispatch of a request\nassociated with a readahead page.\n\nThe above readehead flag is used together with the existing\ninsertion-frequency trigger. The frequency timer will catch read requests\nwhich are not part of a readahead window, but are still part of a\nsequential stream (and therefore dispatched in small time intervals).\n\nChange-Id: Icb7145199c007408de3f267645ccb842e051fd00\nSigned-off-by: Lee Susman <lsusman@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Cyanogenmod11-vee7/android_kernel_lge_vee7/commits/395958eec20ef261a6581a69402a406b15f7fd2b"}]}