{"head":"1125fce0294ab4d7667510accf91e0457b49cd11","size":6,"push_id":44591058,"shas":[["8ddbdce1987c1264973251844757f32afbead79f","ecd1f14f7c1c6dc7a40210bdcc3810e0107ecbc8@android.com","input: evdev: Add missing wake_lock_destroy\n\nChange-Id: Ief1ef44d98a197e5b457f5e8617c413e76e3c6d2\nSigned-off-by: Benoit Goby <benoit@android.com>","Benoit Goby"],["de45929e314018877f3603b249910584aa027d01","77843028b8f8419c9977951e271784ccf7804be9@unimore.it","block: prepare I/O context code for BFQ\n\nBFQ uses struct cfq_io_context to store its per-process per-device data,\nreusing the same code for cic handling of CFQ.  The code is not shared\nATM to minimize the impact of these patches.\n\nThis patch introduces a new hlist to each io_context to store all the\ncic's allocated by BFQ to allow calling the right destructor on module\nunload; the radix tree used for cic lookup needs to be duplicated\nbecause it can contain dead keys inserted by a scheduler and later\nretrieved by the other one.\n\nUpdate the io_context exit and free paths to take care also of\nthe BFQ cic's.\n\nChange the type of cfqq inside struct cfq_io_context to void *\nto use it also for BFQ per-queue data.\n\nA new bfq-specific ioprio_changed field is necessary, too, to avoid\nclobbering cfq's one, so switch ioprio_changed to a bitmap, with one\nelement per scheduler.\n\nSigned-off-by: Fabio Checconi <fabio@gandalf.sssup.it>\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Francesco Allertsen <fallertsen@gmail.com>","Paolo Valente"],["42f13f72728b83bd9c51eddfa21fc87740b6ea0b","77843028b8f8419c9977951e271784ccf7804be9@unimore.it","block: add cgroups, kconfig and build bits for BFQ\n\nAdd a Kconfig option and do the related Makefile changes to compile\nthe BFQ I/O scheduler.  Also let the cgroups subsystem know about the\nBFQ I/O controller.\n\nSigned-off-by: Fabio Checconi <fabio@gandalf.sssup.it>\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>","Paolo Valente"],["368ede445d5691869be117bd07e5f1541e732b57","77843028b8f8419c9977951e271784ccf7804be9@unimore.it","block: introduce the BFQ I/O scheduler\n\nAdd the BFQ-v1-r1 I/O scheduler to 2.6.35.\nThe general structure is borrowed from CFQ, as much of the code. A (bfq_)queue\nis associated to each task doing I/O on a device, and each time a scheduling\ndecision has to be taken a queue is selected and it is served until it expires.\n\nThe main differences are:\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 automaticall\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    - 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 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 classes the bandwidth is distributed\n      in proportion to the weights of each queue.\n\nRegarding what has not changed it is worth noting:\n    - the handling of cfq_io_contexts to associate queues to tasks.\n      Much\n      of the code has been reused just renaming it.  (There is room for\n      code sharing with CFQ but we wanted to minimize the impact of this\n      patch.)\n\n    - The handling of async queues.\n\n    - The handling of idle windows.\n\n    - The handling of merging.\n\n    - The heuristics to assert that a task is worth an idle window (with\n      minor modifications to hw_tag/CIC_SEEKY detection).\n\nSigned-off-by: Fabio Checconi <fabio@gandalf.sssup.it>\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\n\nPorted the following commits to bfq:\n    - cfq-iosched: compact io_context radix_tree (80b15c7389caa)\n    - cfq-iosched: remove dead_key from cfq_io_context (bca4b914b5da3d8e)","paolo"],["95bf370557ab248bd9ddd3bf7d4e0ec0dff3fb63","77843028b8f8419c9977951e271784ccf7804be9@unimore.it","Switch from BFQ-v1 to BFQ-v2 for 2.6.37.\n\nBFQ-v2 provides the following four new features (apparently none of them\nis paid with a loss of aggregate throughput with respect to BFQ-v1).\n\n  - Same low-latency guarantees with and without NCQ.\n\n  - Latency for interactive applications about halved with respect to BFQ-v1.\n\n  - When the low_latency tunable is set, also soft real-time applications\n    now enjoy reduced latency.\n\n  - A very little minimum bandwidth is now guaranteed to the\n    Idle IO-scheduling class also when the other classes are\n    backlogged, just to prevent them from starving.\n\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>","Paolo Valente"],["1125fce0294ab4d7667510accf91e0457b49cd11","7a0d90a1adca681c9953d6feb00cea884ae86124@gmail.com","Switch from BFQ-v2 to BFQ-v2-r1.\n\nImprovements:\n\nWhen the first new request for the active queue arrives during disk idling,\nthe device is not immediately unplugged if this request is small. This prevents\nthe disk to be immediately committed to serve a small request. In fact, further\nrequests are likely to be merged to this one quickly, after which the device is\nunplugged by some block layer function and larger requests are dispatched.\n\nThe idling timeout and the weight-raising max time have been tuned a little bit\ntoo, as detailed below.\n\nReduced a little bit the disk idling timeout for weight-raised\nqueues. This helps reduce latencies for applications made of several\nprocesses that do something and then pass the token to the next\nprocess. By reducing the timeout we reduce the time that may be wasted\nto wait for the next request of a process that has just passed the token,\nand hence that will not issue any new request.\n\nReduced the weight-raising max time from 8 to 7.5 seconds: this\nreduces a little bit the time interval during which a just-started\ndisk-bound process may unproperly be weight-raised.","burst lam"]],"ref":"refs/heads/master"}