commit 4213bdcbad35559368ebe6562fe7167d2f508f42 Author: Alexandre Frade Date: Tue Jun 5 11:41:20 2018 -0300 4.17.0-xanmod1 Signed-off-by: Alexandre Frade commit 6ca5b5e39b3a835a2965a59f5e8e960ebeb1d592 Author: Alexandre Frade Date: Tue Jun 5 11:39:49 2018 -0300 aufs: aufs4.x-rcN 20180430 commit fef9257c02c2937b5663a749176e41969265f3b1 Author: Alexandre Frade Date: Sat Feb 24 03:29:03 2018 +0000 elevator: set default scheduler to bfq-mq for blk-mq Signed-off-by: Alexandre Frade commit 54a32a0892ca485fbf3faded709af6486f202850 Author: Alexandre Frade Date: Mon Jan 29 18:36:35 2018 +0000 block: set rq_affinity = 2 for full multithreading I/O requests Signed-off-by: Alexandre Frade commit 99739167d56e5df761cb03d6f95b02d293ebab5a Author: Alexandre Frade Date: Mon Jan 29 18:29:13 2018 +0000 sched/core: nr_migrate = 128 increases number of tasks to iterate in a single balance run. Signed-off-by: Alexandre Frade commit b9e0d31cebecd1f543586a72b06ba6a9ee434bc6 Author: Alexandre Frade Date: Mon Jan 29 17:55:52 2018 +0000 cpufreq: tunes ondemand governor for performance Signed-off-by: Alexandre Frade commit 6416e8d3ebbe403a55c5de397eeba2710d33e44a Author: Alexandre Frade Date: Mon Jan 29 17:41:29 2018 +0000 disable the localversion "+" tag of a git repo Signed-off-by: Alexandre Frade commit a3eee3eacdf9d731c56b8cb8cda285e1f310f10e Author: Alexandre Frade Date: Mon Jan 29 17:36:22 2018 +0000 mm/zswap: set to use lz4 compressor Signed-off-by: Alexandre Frade commit e0a5e920bf85898d49c43a2ea4de71ee63d1c568 Author: Alexandre Frade Date: Mon Jan 29 17:31:25 2018 +0000 mm/vmscan: vm_swappiness = 30 decreases the amount of swapping Signed-off-by: Alexandre Frade commit e0efb56e9b1f2e074ff5e9c978384ef4a016c82b Author: Alexandre Frade Date: Mon Jan 29 17:26:15 2018 +0000 kconfig: add 500Hz timer interrupt kernel config Signed-off-by: Alexandre Frade commit 75ca9c8cc192dbaa79fcc2a20a6f915c5d7e7617 Author: Alexandre Frade Date: Mon Jan 29 17:21:43 2018 +0000 mm: set 128/2048 (min/max) kilobytes to read-ahead for filesystems on this block device Signed-off-by: Alexandre Frade commit c2b0056c4d650b737e55f49223c5fa0a08a99cf3 Author: Alexandre Frade Date: Mon Jan 29 16:59:22 2018 +0000 dcache: cache_pressure = 50 decreases the rate at which VFS caches are reclaimed Signed-off-by: Alexandre Frade commit 932992b818f97d43c25d2a81fb12c032edf50f17 Author: Alexandre Frade Date: Thu Jul 6 03:03:36 2017 +0000 add trace events for open(), exec() and uselib() Signed-off-by: Alexandre Frade commit 069cbeb5d7244a99c2e7ca013a4212c6983a73f4 Author: Davide Sapienza Date: Wed Apr 11 19:09:32 2018 +0200 block, bfq-sq, bfq-mq: prevent soft_rt_next_start from being stuck at infinity BFQ can deem a bfq_queue as soft real-time only if the queue - periodically becomes completely idle, i.e., empty and with no still-outstanding I/O request; - after becoming idle, gets new I/O only after a special reference time soft_rt_next_start. In this respect, after commit "block, bfq-sq, bfq-mq: consider also past I/O in soft real-time detection", the value of soft_rt_next_start can never decrease. This causes a problem with the following special updating case for soft_rt_next_start: to prevent queues that are not completely idle to be wrongly detected as soft real-time (when they become non-empty again), soft_rt_next_start is temporarily set to infinity for empty queues with still outstanding I/O requests. But, if such an update is actually performed, then, because of the above commit, soft_rt_next_start will be stuck at infinity forever, and the queue will have no more chance to be considered soft real-time. On slow systems, this problem does cause actual soft real-time applications to be occasionally not detected as such. This commit addresses this issue by eliminating the pushing of soft_rt_next_start to infinity, and by changing the way non-empty queues are prevented from being wrongly detected as soft real-time. Simply, a queue that becomes non-empty again can now be detected as soft real-time only if it has no outstanding I/O request. Signed-off-by: Davide Sapienza Signed-off-by: Paolo Valente commit 5c7bd54a2ef0d9b19bc74516ebd9a5a228af96ce Author: Davide Sapienza Date: Thu Feb 1 13:28:18 2018 +0100 block, bfq-sq, bfq-mq: increase weight-raising duration for interactive apps The maximum possible duration of the weight-raising period for interactive applications is limited to 13 seconds, as this is the time needed to load the largest application that we considered when tuning weight raising. Unfortunately, in such an evaluation, we did not consider the case of very slow virtual machines. For example, on a QEMU/KVM virtual machine - running in a slow PC; - with a virtual disk stacked on a slow low-end 5400rpm HDD; - serving a heavy I/O workload, such as the sequential reading of several files; mplayer takes 23 seconds to start, if constantly weight-raised. To address this issue, this commit conservatively sets the upper limit for weight-raising duration to 25 seconds. Signed-off-by: Davide Sapienza Signed-off-by: Paolo Valente commit 31b1d57e0ebddcfb65141071c4958a4a19528e6d Author: Paolo Valente Date: Wed Jan 3 16:23:57 2018 +0100 block, bfq-sq, bfq-mq: remove slow-system class BFQ computes the duration of weight raising for interactive applications automatically, using some reference parameters. In particular, BFQ uses the best durations (see comments in the code for how these durations have been assessed) for two classes of systems: slow and fast ones. Examples of slow systems are old phones or systems using micro HDDs. Fast systems are all the remaining ones. Using these parameters, BFQ computes the actual duration of the weight raising, for the system at hand, as a function of the relative speed of the system w.r.t. the speed of a reference system, belonging to the same class of systems as the system at hand. This slow vs fast differentiation proved to be useful in the past, but happens to have little meaning with current hardware. Even worse, it does cause problems in virtual systems, where the speed of the system can vary frequently, and so widely to just confuse the class-detection mechanism, and, as we have verified experimentally, to cause BFQ to compute non-sensical weight-raising durations. This commit addresses this issues by removing the slow class and the class-detection mechanism. Signed-off-by: Paolo Valente commit 8c88cbe95ced8cbf67f6b1ebdcebc790d3e18d1e Author: Paolo Valente Date: Wed Apr 11 10:40:58 2018 +0200 block, bfq-sq, bfq-mq: add description of weight-raising heuristics A description of how weight raising works is missing in BFQ sources. In addition, the code for handling weight raising is scattered across a few functions. This makes it rather hard to understand the mechanism and its rationale. This commits adds such a description at the beginning of the main source file. Signed-off-by: Paolo Valente commit 902cac838314dadbf2d07180dd2e18fa43c2ecae Author: Filippo Muzzini Date: Tue Apr 17 07:47:15 2018 +0200 block, bfq-mq: remove the removal of 'next' rq in bfq_requests_merged Since bfq_finish_request() is always called on the request 'next', after bfq_requests_merged() is finished, and bfq_finish_request() removes 'next' from its bfq_queue if needed, it isn't necessary to do such a removal in advance in bfq_merged_requests(). This commit removes such a useless 'next' removal. Signed-off-by: Filippo Muzzini Signed-off-by: Paolo Valente commit 0d3286b2173aaa4130d5a17f886c0438022c2428 Author: Paolo Valente Date: Tue Apr 17 07:47:14 2018 +0200 block, bfq-mq: remove wrong check in bfq_requests_merged The request rq passed to the function bfq_requests_merged is always in a bfq_queue, so the check !RB_EMPTY_NODE(&rq->rb_node) at the beginning of bfq_requests_merged always succeeds, and the control flow systematically skips to the end of the function. This implies that the body of the function is never executed, i.e., the repositioning of rq is never performed. On the opposite end, a control is missing in the body of the function: 'next' must be removed only if it is inside a bfq_queue. This commit removes the wrong check on rq, and adds the missing check on 'next'. In addition, this commit adds comments on bfq_requests_merged. Signed-off-by: Filippo Muzzini Signed-off-by: Paolo Valente commit 6984150be2de5d1488d89f5377a462bd9aaad208 Author: Filippo Muzzini Date: Tue Apr 17 07:47:13 2018 +0200 block, bfq-mq: remove wrong lock in bfq_requests_merged In bfq_requests_merged(), there is a deadlock because the lock on bfqq->bfqd->lock is held by the calling function, but the code of this function tries to grab the lock again. This deadlock is currently hidden by another bug (fixed by next commit for this source file), which causes the body of bfq_requests_merged() to be never executed. This commit removes the deadlock by replacing the lock/unlock pair with lockdep_assert_held. Signed-off-by: Filippo Muzzini Signed-off-by: Paolo Valente commit f32ad7cf92b2f915931a99f583afb9f711bc4ca2 Author: Paolo Valente Date: Fri May 4 16:20:46 2018 +0200 block, bfq-mq: postpone rq preparation to insert or merge When invoked for an I/O request rq, the prepare_request hook of bfq increments reference counters in the destination bfq_queue for rq. In this respect, after this hook has been invoked, rq may still be transformed into a request with no icq attached, i.e., for bfq, a request not associated with any bfq_queue. No further hook is invoked to signal this tranformation to bfq (in general, to the destination elevator for rq). This leads bfq into an inconsistent state, because bfq has no chance to correctly lower these counters back. This inconsistency may in its turn cause incorrect scheduling and hangs. It certainly causes memory leaks, by making it impossible for bfq to free the involved bfq_queue. On the bright side, no transformation can still happen for rq after rq has been inserted into bfq, or merged with another, already inserted, request. Exploiting this fact, this commit addresses the above issue by delaying the preparation of an I/O request to when the request is inserted or merged. This change also gives a performance bonus: a lock-contention point gets removed. To prepare a request, bfq needs to hold its scheduler lock. After postponing request preparation to insertion or merging, no lock needs to be grabbed any longer in the prepare_request hook, while the lock already taken to perform insertion or merging is used to preparare the request as well. Signed-off-by: Paolo Valente commit 4f182296bf0d52ed6732018e769340ddf667f626 Author: Paolo Valente Date: Wed Apr 4 11:28:16 2018 +0200 block, bfq-sq, bfq-mq: lower-bound the estimated peak rate to 1 If a storage device handled by BFQ happens to be slower than 7.5 KB/s for a certain amount of time (in the order of a second), then the estimated peak rate of the device, maintained in BFQ, becomes equal to 0. The reason is the limited precision with which the rate is represented (details on the range of representable values in the comments introduced by this commit). This leads to a division-by-zero error where the estimated peak rate is used as divisor. Such a type of failure has been reported in [1]. This commit addresses this issue by: 1. Lower-bounding the estimated peak rate to 1 2. Adding and improving comments on the range of rates representable [1] https://www.spinics.net/lists/kernel/msg2739205.html Signed-off-by: Konstantin Khlebnikov Signed-off-by: Paolo Valente commit 017bfa7abec6da2ff6dd8ebab487e29e56df04df Author: Melzani Alessandro Date: Mon Feb 26 22:59:30 2018 +0100 bfq-sq, bfq-mq: port of "block, bfq: fix error handle in bfq_init" if elv_register fail, bfq_pool should be free. Signed-off-by: Alessandro Melzani commit ba49dfb95ad672d652d0dca6a0dde56198c55671 Author: Melzani Alessandro Date: Mon Feb 26 22:43:30 2018 +0100 bfq-sq, bfq-mq: port of "bfq: Use icq_to_bic() consistently" Some code uses icq_to_bic() to convert an io_cq pointer to a bfq_io_cq pointer while other code uses a direct cast. Convert the code that uses a direct cast such that it uses icq_to_bic(). Signed-off-by: Alessandro Melzani commit 94d42d61f69a9178f9ba3630832ef33b3c09191c Author: Melzani Alessandro Date: Mon Feb 26 22:21:59 2018 +0100 bfq-mq: port of "block, bfq: remove batches of confusing ifdefs" Commit a33801e8b473 ("block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs: one reported in [1], plus a similar one in another function. This commit removes both batches, in the way suggested in [1]. [1] https://www.spinics.net/lists/linux-block/msg20043.html Fixes: a33801e8b473 ("block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP") Signed-off-by: Alessandro Melzani commit f3d2ef943403167c06b06475d019a7bf890bcf75 Author: Davide Paganelli Date: Thu Feb 8 11:49:58 2018 +0100 block, bfq-mq, bfq-sq: make bfq_bfqq_expire print expiration reason Improve readability of the log messages related to the expiration reasons of the function bfq_bfqq_expire. Change the printing of the number that represents the reason for expiration with an actual textual description of the reason. Signed-off-by: Davide Paganelli Signed-off-by: Paolo Valente commit 2f6e1b621e5dd9f0cd159fe6b56beb5db66389bf Author: Davide Paganelli Date: Thu Feb 8 12:19:24 2018 +0100 block, bfq-mq, bfq-sq: make log functions print names of calling functions Add the macro __func__ as a parameter to the invocations of the functions pr_crit, blk_add_trace_msg and blk_add_cgroup_trace_msg in bfq_log* functions, in order to include automatically in the log messages the names of the functions that call the log functions. The programmer can then avoid doing it. Signed-off-by: Davide Paganelli Signed-off-by: Paolo Valente commit b0d72704a127d8f8866b5739da5e83e66ff9fa4e Author: Paolo Valente Date: Mon Jan 15 15:07:05 2018 +0100 block, bfq-mq: add requeue-request hook Commit 'a6a252e64914 ("blk-mq-sched: decide how to handle flush rq via RQF_FLUSH_SEQ")' makes all non-flush re-prepared requests for a device be re-inserted into the active I/O scheduler for that device. As a consequence, I/O schedulers may get the same request inserted again, even several times, without a finish_request invoked on that request before each re-insertion. This fact is the cause of the failure reported in [1]. For an I/O scheduler, every re-insertion of the same re-prepared request is equivalent to the insertion of a new request. For schedulers like mq-deadline or kyber, this fact causes no harm. In contrast, it confuses a stateful scheduler like BFQ, which keeps state for an I/O request, until the finish_request hook is invoked on the request. In particular, BFQ may get stuck, waiting forever for the number of request dispatches, of the same request, to be balanced by an equal number of request completions (while there will be one completion for that request). In this state, BFQ may refuse to serve I/O requests from other bfq_queues. The hang reported in [1] then follows. However, the above re-prepared requests undergo a requeue, thus the requeue_request hook of the active elevator is invoked for these requests, if set. This commit then addresses the above issue by properly implementing the hook requeue_request in BFQ. [1] https://marc.info/?l=linux-block&m=151211117608676 Reported-by: Ivan Kozik Reported-by: Alban Browaeys Signed-off-by: Paolo Valente Signed-off-by: Serena Ziviani commit 121d079870bbf7b042a52b71a96c6c196a14200a Author: Paolo Valente Date: Sat Jan 13 18:48:41 2018 +0100 block, bfq-sq, bfq-mq: remove trace_printks Commit ("block, bfq-sq, bfq-mq: trace get and put of bfq groups") unwisely added some invocations of the function trace_printk, which is inappropriate in production kernels. This commit removes those invocations. Signed-off-by: Paolo Valente commit cbc2c905042f91bb8a55212515be60e15dc066bb Author: Paolo Valente Date: Wed Jan 10 09:08:22 2018 +0100 bfq-sq, bfq-mq: compile group put for oom queue only if BFQ_GROUP_IOSCHED is set Commit ("bfq-sq, bfq-mq: release oom-queue ref to root group on exit") added a missing put of the root bfq group for the oom queue. That put has to be, and can be, performed only if CONFIG_BFQ_GROUP_IOSCHED is defined: the function doing the put is even not defined at all if CONFIG_BFQ_GROUP_IOSCHED is not defined. But that commit makes that put be invoked regardless of whether CONFIG_BFQ_GROUP_IOSCHED is defined. This commit fixes this mistake, by making that invocation be compiled only if CONFIG_BFQ_GROUP_IOSCHED is actually defined. Fixes ("block, bfq: release oom-queue ref to root group on exit") Reported-by: Jan Alexander Steffens Signed-off-by: Paolo Valente commit 47e4f0e499f18e511d7c64e24e036cb943085ce9 Author: Paolo Valente Date: Mon Jan 8 19:40:38 2018 +0100 block, bfq-sq, bfq-mq: trace get and put of bfq groups Signed-off-by: Paolo Valente commit d158b8071f97ad6d2203013cbccd343b0d7d08ec Author: Paolo Valente Date: Mon Jan 8 19:38:45 2018 +0100 bfq-sq, bfq-mq: release oom-queue ref to root group on exit On scheduler init, a reference to the root group, and a reference to its corresponding blkg are taken for the oom queue. Yet these references are not released on scheduler exit, which prevents these objects from be freed. This commit adds the missing reference releases. Reported-by: Davide Ferrari Signed-off-by: Paolo Valente commit 7b32284c2c50b48733969d0ed899b1f7be730605 Author: Paolo Valente Date: Thu Jan 4 16:29:58 2018 +0100 bfq-sq, bfq-mq: put async queues for root bfq groups too For each pair [device for which bfq is selected as I/O scheduler, group in blkio/io], bfq maintains a corresponding bfq group. Each such bfq group contains a set of async queues, with each async queue created on demand, i.e., when some I/O request arrives for it. On creation, an async queue gets an extra reference, to make sure that the queue is not freed as long as its bfq group exists. Accordingly, to allow the queue to be freed after the group exited, this extra reference must released on group exit. The above holds also for a bfq root group, i.e., for the bfq group corresponding to the root blkio/io root for a given device. Yet, by mistake, the references to the existing async queues of a root group are not released when the latter exits. This causes a memory leak when the instance of bfq for a given device exits. In a similar vein, bfqg_stats_xfer_dead is not executed for a root group. This commit fixes bfq_pd_offline so that the latter executes the above missing operations for a root group too. Reported-by: Holger Hoffstätte Reported-by: Guoqing Jiang Signed-off-by: Davide Ferrari Signed-off-by: Paolo Valente commit ae2c6e44d0191713265e892f59a1111dff47b407 Author: Paolo Valente Date: Thu Dec 21 15:51:39 2017 +0100 bfq-sq, bfq-mq: limit sectors served with interactive weight raising To maximise responsiveness, BFQ raises the weight, and performs device idling, for bfq_queues associated with processes deemed as interactive. In particular, weight raising has a maximum duration, equal to the time needed to start a large application. If a weight-raised process goes on doing I/O beyond this maximum duration, it loses weight-raising. This mechanism is evidently vulnerable to the following false positives: I/O-bound applications that will go on doing I/O for much longer than the duration of weight-raising. These applications have basically no benefit from being weight-raised at the beginning of their I/O. On the opposite end, while being weight-raised, these applications a) unjustly steal throughput to applications that may truly need low latency; b) make BFQ uselessly perform device idling; device idling results in loss of device throughput with most flash-based storage, and may increase latencies when used purposelessly. This commit adds a countermeasure to reduce both the above problems. To introduce this countermeasure, we provide the following extra piece of information (full details in the comments added by this commit). During the start-up of the large application used as a reference to set the duration of weight-raising, involved processes transfer at most ~110K sectors each. Accordingly, a process initially deemed as interactive has no right to be weight-raised any longer, once transferred 110K sectors or more. Basing on this consideration, this commit early-ends weight-raising for a bfq_queue if the latter happens to have received an amount of service at least equal to 110K sectors (actually, a little bit more, to keep a safety margin). I/O-bound applications that reach a high throughput, such as file copy, get to this threshold much before the allowed weight-raising period finishes. Thus this early ending of weight-raising reduces the amount of time during which these applications cause the problems described above. Signed-off-by: Paolo Valente commit 3246a637fdb69f8355e0434ff6de2e4b2a7b961d Author: Paolo Valente Date: Tue Dec 19 12:07:12 2017 +0100 block, bfq-mq: limit tags for writes and async I/O Asynchronous I/O can easily starve synchronous I/O (both sync reads and sync writes), by consuming all request tags. Similarly, storms of synchronous writes, such as those that sync(2) may trigger, can starve synchronous reads. In their turn, these two problems may also cause BFQ to loose control on latency for interactive and soft real-time applications. For example, on a PLEXTOR PX-256M5S SSD, LibreOffice Writer takes 0.6 seconds to start if the device is idle, but it takes more than 45 seconds (!) if there are sequential writes in the background. This commit addresses this issue by limiting the maximum percentage of tags that asynchronous I/O requests and synchronous write requests can consume. In particular, this commit grants a higher threshold to synchronous writes, to prevent the latter from being starved by asynchronous I/O. According to the above test, LibreOffice Writer now starts in about 1.2 seconds on average, regardless of the background workload, and apart from some rare outlier. To check this improvement, run, e.g., sudo ./comm_startup_lat.sh bfq-mq 5 5 seq 10 "lowriter --terminate_after_init" for the comm_startup_lat benchmark in the S suite [1]. [1] https://github.com/Algodev-github/S Signed-off-by: Paolo Valente commit 55ddcbc1e33734465e42d9e32c8af0228f79c703 Author: Chiara Bruschi Date: Mon Dec 11 18:55:26 2017 +0100 block, bfq-sq, bfq-mq: specify usage condition of delta_us in bfq_log_bfqq call Inside the function bfq_completed_request the value of a variable called delta_us is computed as current request completion time. delta_us is used inside a call to the function bfq_log_bfqq as divisor in a division operation to compute a rate value, but no check makes sure that delta_us has non-zero value. A divisor with value 0 leads to a division error that could result in a kernel oops (therefore unstable/unreliable system state) and consequently cause kernel panic if resources are unavailable after the system fault. This commit fixes this call to bfq_log_bfqq specifying the condition that allows delta_us to be safely used as divisor. Signed-off-by: Paolo Valente Signed-off-by: Chiara Bruschi commit 9b5b8bae5f6f4771ff3694de56244ff99b34e7a0 Author: Paolo Valente Date: Thu Nov 30 17:48:28 2017 +0100 block, bfq-sq, bfq-mq: increase threshold to deem I/O as random If two processes do I/O close to each other, i.e., are cooperating processes in BFQ (and CFQ'S) nomenclature, then BFQ merges their associated bfq_queues, so as to get sequential I/O from the union of the I/O requests of the processes, and thus reach a higher throughput. A merged queue is then split if its I/O stops being sequential. In this respect, BFQ deems the I/O of a bfq_queue as (mostly) sequential only if less than 4 I/O requests are random, out of the last 32 requests inserted into the queue. Unfortunately, extensive testing (with the interleaved_io benchmark of the S suite [1], and with real applications spawning cooperating processes) has clearly shown that, with such a low threshold, only a rather low I/O throughput may be reached when several cooperating processes do I/O. In particular, the outcome of each test run was bimodal: if queue merging occurred and was stable during the test, then the throughput was close to the peak rate of the storage device, otherwise the throughput was arbitrarily low (usually around 1/10 of the peak rate with a rotational device). The probability to get the unlucky outcomes grew with the number of cooperating processes: it was already significant with 5 processes, and close to one with 7 or more processes. The cause of the low throughput in the unlucky runs was that the merged queues containing the I/O of these cooperating processes were soon split, because they contained more random I/O requests than those tolerated by the 4/32 threshold, but - that I/O would have however allowed the storage device to reach peak throughput or almost peak throughput; - in contrast, the I/O of these processes, if served individually (from separate queues) yielded a rather low throughput. So we repeated our tests with increasing values of the threshold, until we found the minimum value (19) for which we obtained maximum throughput, reliably, with at least up to 9 cooperating processes. Then we checked that the use of that higher threshold value did not cause any regression for any other benchmark in the suite [1]. This commit raises the threshold to such a higher value. [1] https://github.com/Algodev-github/S Signed-off-by: Angelo Ruocco Signed-off-by: Paolo Valente commit b56d7d975026a2d5304efa622f395d5de697e129 Author: Angelo Ruocco Date: Mon Dec 11 14:19:54 2017 +0100 block, bfq-sq, bfq-mq: remove superfluous check in queue-merging setup When two or more processes do I/O in a way that the their requests are sequential in respect to one another, BFQ merges the bfq_queues associated with the processes. This way the overall I/O pattern becomes sequential, and thus there is a boost in througput. These cooperating processes usually start or restart to do I/O shortly after each other. So, in order to avoid merging non-cooperating processes, BFQ ensures that none of these queues has been in weight raising for too long. In this respect, from commit "block, bfq-sq, bfq-mq: let a queue be merged only shortly after being created", BFQ checks whether any queue (and not only weight-raised ones) is doing I/O continuously from too long to be merged. This new additional check makes the first one useless: a queue doing I/O from long enough, if being weight-raised, is also a queue in weight raising for too long to be merged. Accordingly, this commit removes the first check. Signed-off-by: Angelo Ruocco Signed-off-by: Paolo Valente commit 21fcbf13db2100f72f498ac7dd5cd9f6f8a95b88 Author: Paolo Valente Date: Fri Oct 27 11:12:14 2017 +0200 block, bfq-sq, bfq-mq: let a queue be merged only shortly after starting I/O In BFQ and CFQ, two processes are said to be cooperating if they do I/O in such a way that the union of their I/O requests yields a sequential I/O pattern. To get such a sequential I/O pattern out of the non-sequential pattern of each cooperating process, BFQ and CFQ merge the queues associated with these processes. In more detail, cooperating processes, and thus their associated queues, usually start, or restart, to do I/O shortly after each other. This is the case, e.g., for the I/O threads of KVM/QEMU and of the dump utility. Basing on this assumption, this commit allows a bfq_queue to be merged only during a short time interval (100ms) after it starts, or re-starts, to do I/O. This filtering provides two important benefits. First, it greatly reduces the probability that two non-cooperating processes have their queues merged by mistake, if they just happen to do I/O close to each other for a short time interval. These spurious merges cause loss of service guarantees. A low-weight bfq_queue may unjustly get more than its expected share of the throughput: if such a low-weight queue is merged with a high-weight queue, then the I/O for the low-weight queue is served as if the queue had a high weight. This may damage other high-weight queues unexpectedly. For instance, because of this issue, lxterminal occasionally took 7.5 seconds to start, instead of 6.5 seconds, when some sequential readers and writers did I/O in the background on a FUJITSU MHX2300BT HDD. The reason is that the bfq_queues associated with some of the readers or the writers were merged with the high-weight queues of some processes that had to do some urgent but little I/O. The readers then exploited the inherited high weight for all or most of their I/O, during the start-up of terminal. The filtering introduced by this commit eliminated any outlier caused by spurious queue merges in our start-up time tests. This filtering also provides a little boost of the throughput sustainable by BFQ: 3-4%, depending on the CPU. The reason is that, once a bfq_queue cannot be merged any longer, this commit makes BFQ stop updating the data needed to handle merging for the queue. Signed-off-by: Paolo Valente Signed-off-by: Angelo Ruocco commit f90373d317a80e712c6097a48c7a8688ff7420df Author: Angelo Ruocco Date: Mon Dec 18 08:28:08 2017 +0100 block, bfq-sq, bfq-mq: check low_latency flag in bfq_bfqq_save_state() A just-created bfq_queue will certainly be deemed as interactive on the arrival of its first I/O request, if the low_latency flag is set. Yet, if the queue is merged with another queue on the arrival of its first I/O request, it will not have the chance to be flagged as interactive. Nevertheless, if the queue is then split soon enough, it has to be flagged as interactive after the split. To handle this early-merge scenario correctly, BFQ saves the state of the queue, on the merge, as if the latter had already been deemed interactive. So, if the queue is split soon, it will get weight-raised, because the previous state of the queue is resumed on the split. Unfortunately, in the act of saving the state of the newly-created queue, BFQ doesn't check whether the low_latency flag is set, and this causes early-merged queues to be then weight-raised, on queue splits, even if low_latency is off. This commit addresses this problem by adding the missing check. Signed-off-by: Angelo Ruocco Signed-off-by: Paolo Valente commit 1ade78447a5b8ca06d8a67e100c83bf89e54d595 Author: Paolo Valente Date: Thu Nov 16 18:38:13 2017 +0100 block, bfq-sq, bfq-mq: add missing rq_pos_tree update on rq removal If two processes do I/O close to each other, then BFQ merges the bfq_queues associated with these processes, to get a more sequential I/O, and thus a higher throughput. In this respect, to detect whether two processes are doing I/O close to each other, BFQ keeps a list of the head-of-line I/O requests of all active bfq_queues. The list is ordered by initial sectors, and implemented through a red-black tree (rq_pos_tree). Unfortunately, the update of the rq_pos_tree was incomplete, because the tree was not updated on the removal of the head-of-line I/O request of a bfq_queue, in case the queue did not remain empty. This commit adds the missing update. Signed-off-by: Paolo Valente Signed-off-by: Angelo Ruocco commit 32635b662d06cccf5493554c82d031637071a120 Author: Chiara Bruschi Date: Thu Dec 7 09:57:19 2017 +0100 block, bfq-mq: fix occurrences of request prepare/finish methods' old names Commits 'b01f1fa3bb19' (Port of "blk-mq-sched: unify request prepare methods") and 'cc10d2d7d2c1' (Port of "blk-mq-sched: unify request finished methods") changed the old names of current bfq_prepare_request and bfq_finish_request methods, but left them unchanged elsewhere in the code (related comments, part of function name bfq_put_rq_priv_body). This commit fixes every occurrence of the old names of these methods by changing them into the current names. Fixes: b01f1fa3bb19 (Port of "blk-mq-sched: unify request prepare methods") Fixes: cc10d2d7d2c1 (Port of "blk-mq-sched: unify request finished methods") Reviewed-by: Paolo Valente Signed-off-by: Federico Motta Signed-off-by: Chiara Bruschi commit 387803ef9186ce7bb0089152e40b11348a0b8abe Author: Paolo Valente Date: Sun Nov 12 22:43:46 2017 +0100 block, bfq-sq, bfq-mq: consider also past I/O in soft real-time detection BFQ privileges the I/O of soft real-time applications, such as video players, to guarantee to these application a high bandwidth and a low latency. In this respect, it is not easy to correctly detect when an application is soft real-time. A particularly nasty false positive is that of an I/O-bound application that occasionally happens to meet all requirements to be deemed as soft real-time. After being detected as soft real-time, such an application monopolizes the device. Fortunately, BFQ will realize soon that the application is actually not soft real-time and suspend every privilege. Yet, the application may happen again to be wrongly detected as soft real-time, and so on. As highlighted by our tests, this problem causes BFQ to occasionally fail to guarantee a high responsiveness, in the presence of heavy background I/O workloads. The reason is that the background workload happens to be detected as soft real-time, more or less frequently, during the execution of the interactive task under test. To give an idea, because of this problem, Libreoffice Writer occasionally takes 8 seconds, instead of 3, to start up, if there are sequential reads and writes in the background, on a Kingston SSDNow V300. This commit addresses this issue by leveraging the following facts. The reason why some applications are detected as soft real-time despite all BFQ checks to avoid false positives, is simply that, during high CPU or storage-device load, I/O-bound applications may happen to do I/O slowly enough to meet all soft real-time requirements, and pass all BFQ extra checks. Yet, this happens only for limited time periods: slow-speed time intervals are usually interspersed between other time intervals during which these applications do I/O at a very high speed. To exploit these facts, this commit introduces a little change, in the detection of soft real-time behavior, to systematically consider also the recent past: the higher the speed was in the recent past, the later next I/O should arrive for the application to be considered as soft real-time. At the beginning of a slow-speed interval, the minimum arrival time allowed for the next I/O usually happens to still be so high, to fall *after* the end of the slow-speed period itself. As a consequence, the application does not risk to be deemed as soft real-time during the slow-speed interval. Then, during the next high-speed interval, the application cannot, evidently, be deemed as soft real-time (exactly because of its speed), and so on. This extra filtering proved to be rather effective: in the above test, the frequency of false positives became so low that the start-up time was 3 seconds in all iterations (apart from occasional outliers, caused by page-cache-management issues, which are out of the scope of this commit, and cannot be solved by an I/O scheduler). Signed-off-by: Paolo Valente Signed-off-by: Angelo Ruocco commit be7bf69c1ae933d022aa63e499485b2dc1512f3f Author: Paolo Valente Date: Tue Nov 14 08:28:45 2017 +0100 block, bfq-mq: turn BUG_ON on request-size into WARN_ON BFQ has many checks of internal and external consistency. One of them checks that an I/O request has still sectors to serve, if it happens to be retired without being served. If the request has no sector to serve, a BUG_ON signals the failure and causes the kernel to terminate. Yet, from a crash report by a user [1], this condition may happen to hold, in apparently correct functioning, for I/O with a CD/DVD. To address this issue, this commit turns the above BUG_ON into a WARN_ON. This commit also adds a companion WARN_ON on request insertion into the scheduler. [1] https://groups.google.com/d/msg/bfq-iosched/DDOTJBroBa4/VyU1zUFtCgAJ Reported-by: Alexandre Frade Signed-off-by: Paolo Valente commit 53d514c383161ad8972f663dd857fd08ffcf842a Author: Luca Miccio Date: Wed Nov 8 19:07:41 2017 +0100 block, bfq-sq, bfq-mq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP BFQ (both bfq-mq and bfq-sq) currently creates, and updates, its own instance of the whole set of blkio statistics that cfq creates. Yet, from the comments of Tejun Heo in [1], it turned out that most of these statistics are meant/useful only for debugging. This commit makes BFQ create the latter, debugging statistics only if the option CONFIG_DEBUG_BLK_CGROUP is set. By doing so, this commit also enables BFQ to enjoy a high perfomance boost. The reason is that, if CONFIG_DEBUG_BLK_CGROUP is not set, then BFQ has to update far fewer statistics, and, in particular, not the heaviest to update. To give an idea of the benefits, if CONFIG_DEBUG_BLK_CGROUP is not set, then, on an Intel i7-4850HQ, and with 8 threads doing random I/O in parallel on null_blk (configured with 0 latency), the throughput of bfq-mq grows from 310 to 400 KIOPS (+30%). We have measured similar or even much higher boosts with other CPUs: e.g., +45% with an ARM CortexTM-A53 Octa-core. Our results have been obtained and can be reproduced very easily with the script in [1]. [1] https://www.spinics.net/lists/linux-block/msg18943.html Suggested-by: Tejun Heo Suggested-by: Ulf Hansson Signed-off-by: Luca Miccio Signed-off-by: Paolo Valente commit 402aae47ec33d447b8146c871935e4a3314a2f45 Author: Paolo Valente Date: Wed Nov 8 19:07:40 2017 +0100 block, bfq-mq: update blkio stats outside the scheduler lock bfq-mq invokes various blkg_*stats_* functions to update the statistics contained in the special files blkio.bfq-mq.* in the blkio controller groups, i.e., the I/O accounting related to the proportional-share policy provided by bfq-mq. The execution of these functions takes a considerable percentage, about 40%, of the total per-request execution time of bfq-mq (i.e., of the sum of the execution time of all the bfq-mq functions that have to be executed to process an I/O request from its creation to its destruction). This reduces the request-processing rate sustainable by bfq-mq noticeably, even on a multicore CPU. In fact, the bfq-mq functions that invoke blkg_*stats_* functions cannot be executed in parallel with the rest of the code of bfq-mq, because both are executed under the same same per-device scheduler lock. To reduce this slowdown, this commit moves, wherever possible, the invocation of these functions (more precisely, of the bfq-mq functions that invoke blkg_*stats_* functions) outside the critical sections protected by the scheduler lock. With this change, and with all blkio.bfq-mq.* statistics enabled, the throughput grows, e.g., from 250 to 310 KIOPS (+25%) on an Intel i7-4850HQ, in case of 8 threads doing random I/O in parallel on null_blk, with the latter configured with 0 latency. We obtained the same or higher throughput boosts, up to +30%, with other processors (some figures are reported in the documentation). For our tests, we used the script [1], with which our results can be easily reproduced. NOTE. This commit still protects the invocation of blkg_*stats_* functions with the request_queue lock, because the group these functions are invoked on may otherwise disappear before or while these functions are executed. Fortunately, tests without even this lock show, by difference, that the serialization caused by this lock has a little impact (at most ~5% of throughput reduction). [1] https://github.com/Algodev-github/IOSpeed Signed-off-by: Paolo Valente Signed-off-by: Luca Miccio commit 58b6afa0a02a8d72820d695d8fba17d08c8113cd Author: Luca Miccio Date: Tue Oct 31 09:50:11 2017 +0100 block, bfq-mq: add missing invocations of bfqg_stats_update_io_add/remove bfqg_stats_update_io_add and bfqg_stats_update_io_remove are to be invoked, respectively, when an I/O request enters and when an I/O request exits the scheduler. Unfortunately, bfq-mq does not fully comply with this scheme, because it does not invoke these functions for requests that are inserted into or extracted from its priority dispatch list. This commit fixes this mistake. Signed-off-by: Paolo Valente Signed-off-by: Luca Miccio commit 94eede892f1f488051f6658882c2bb3997c3d5a0 Author: Paolo Valente Date: Mon Oct 30 16:50:50 2017 +0100 doc, block, bfq-mq: update max IOPS sustainable with BFQ We have investigated more deeply the performance of BFQ, in terms of number of IOPS that can be processed by the CPU when BFQ is used as I/O scheduler. In more detail, using the script [1], we have measured the number of IOPS reached on top of a null block device configured with zero latency, as a function of the workload (sequential read, sequential write, random read, random write) and of the system (we considered desktops, laptops and embedded systems). Basing on the resulting figures, with this commit we update the current, conservative IOPS range reported in BFQ documentation. In particular, the documentation now reports, for each of three different systems, the lowest number of IOPS obtained for that system with the above test (namely, the value obtained with the workload leading to the lowest IOPS). [1] https://github.com/Algodev-github/IOSpeed Signed-off-by: Paolo Valente Signed-off-by: Luca Miccio commit e554d5ed74bf504c4575fe4cdacf25b090911e56 Author: Paolo Valente Date: Fri Oct 6 19:35:38 2017 +0200 bfq-sq, bfq-mq: fix unbalanced decrements of burst size The commit "bfq-sq, bfq-mq: decrease burst size when queues in burst exit" introduced the decrement of burst_size on the removal of a bfq_queue from the burst list. Unfortunately, this decrement can happen to be performed even when burst size is already equal to 0, because of unbalanced decrements. A description follows of the cause of these unbalanced decrements, namely a wrong assumption, and of the way how this wrong assumption leads to unbalanced decrements. The wrong assumption is that a bfq_queue can exit only if the process associated with the bfq_queue has exited. This is false, because a bfq_queue, say Q, may exit also as a consequence of a merge with another bfq_queue. In this case, Q exits because the I/O of its associated process has been redirected to another bfq_queue. The decrement unbalance occurs because Q may then be re-created after a split, and added back to the current burst list, *without* incrementing burst_size. burst_size is not incremented because Q is not a new bfq_queue added to the burst list, but a bfq_queue only temporarily removed from the list, and, before the commit "bfq-sq, bfq-mq: decrease burst size when queues in burst exit", burst_size was not decremented when Q was removed. This commit addresses this issue by just checking whether the exiting bfq_queue is a merged bfq_queue, and, in that case, not decrementing burst_size. Unfortunately, this still leaves room for unbalanced decrements, in the following rarer case: on a split, the bfq_queue happens to be inserted into a different burst list than that it was removed from when merged. If this happens, the number of elements in the new burst list becomes higher than burst_size (by one). When the bfq_queue then exits, it is of course not in a merged state any longer, thus burst_size is decremented, which results in an unbalanced decrement. To handle this sporadic, unlucky case in a simple way, this commit also checks that burst_size is larger than 0 before decrementing it. Finally, this commit removes an useless, extra check: the check that the bfq_queue is sync, performed before checking whether the bfq_queue is in the burst list. This extra check is redundant, because only sync bfq_queues can be inserted into the burst list. Reported-by: Philip Müller Signed-off-by: Paolo Valente Signed-off-by: Angelo Ruocco Tested-by: Philip Müller Tested-by: Oleksandr Natalenko Tested-by: Lee Tibbert commit dd868f372a6771e7b0ead01b9aa8f943abc6e85c Author: omcira Date: Mon Sep 18 10:49:48 2017 +0200 bfq-sq, bfq-mq: decrease burst size when queues in burst exit If many queues belonging to the same group happen to be created shortly after each other, then the concurrent processes associated with these queues have typically a common goal, and they get it done as soon as possible if not hampered by device idling. Examples are processes spawned by git grep, or by systemd during boot. As for device idling, this mechanism is currently necessary for weight raising to succeed in its goal: privileging I/O. In view of these facts, BFQ does not provide the above queues with either weight raising or device idling. On the other hand, a burst of queue creations may be caused also by the start-up of a complex application. In this case, these queues need usually to be served one after the other, and as quickly as possible, to maximise responsiveness. Therefore, in this case the best strategy is to weight-raise all the queues created during the burst, i.e., the exact opposite of the strategy for the above case. To distinguish between the two cases, BFQ uses an empirical burst-size threshold, found through extensive tests and monitoring of daily usage. Only large bursts, i.e., burst with a size above this threshold, are considered as generated by a high number of parallel processes. In this respect, upstart-based boot proved to be rather hard to detect as generating a large burst of queue creations, because with upstart most of the queues created in a burst exit *before* the next queues in the same burst are created. To address this issue, I changed the burst-detection mechanism so as to not decrease the size of the current burst even if one of the queues in the burst is eliminated. Unfortunately, this missing decrease causes false positives on very fast systems: on the start-up of a complex application, such as libreoffice writer, so many queues are created, served and exited shortly after each other, that a large burst of queue creations is wrongly detected as occurring. These false positives just disappear if the size of a burst is decreased when one of the queues in the burst exits. This commit restores the missing burst-size decrease, relying of the fact that upstart is apparently unlikely to be used on systems running this and future versions of the kernel. Signed-off-by: Paolo Valente Signed-off-by: Mauro Andreolini Signed-off-by: Angelo Ruocco Tested-by: Mirko Montanari commit daee81b124900e10d090c9f79c97d4d5a50d5053 Author: Paolo Valente Date: Fri Sep 15 04:58:33 2017 -0400 bfq-sq, bfq-mq: let early-merged queues be weight-raised on split too A just-created bfq_queue, say Q, may happen to be merged with another bfq_queue on the very first invocation of the function __bfq_insert_request. In such a case, even if Q would clearly deserve interactive weight raising (as it has just been created), the function bfq_add_request does not make it to be invoked for Q, and thus to activate weight raising for Q. As a consequence, when the state of Q is saved for a possible future restore, after a split of Q from the other bfq_queue(s), such a state happens to be (unjustly) non-weight-raised. Then the bfq_queue will not enjoy any weight raising on the split, even if should still be in an interactive weight-raising period when the split occurs. This commit solves this problem as follows, for a just-created bfq_queue that is being early-merged: it stores directly, in the saved state of the bfq_queue, the weight-raising state that would have been assigned to the bfq_queue if not early-merged. Signed-off-by: Paolo Valente Tested-by: Angelo Ruocco Tested-by: Mirko Montanari commit a0f8d9669c5b5b73ecfd90e338ad77bf53f8742a Author: Paolo Valente Date: Fri Sep 15 01:53:51 2017 -0400 bfq-sq, bfq-mq: check and switch back to interactive wr also on queue split As already explained in the message of commit "bfq-mq, bfq-sq: fix wrong init of saved start time for weight raising", if a soft real-time weight-raising period happens to be nested in a larger interactive weight-raising period, then BFQ restores the interactive weight raising at the end of the soft real-time weight raising. In particular, BFQ checks whether the latter has ended only on request dispatches. Unfortunately, the above scheme fails to restore interactive weight raising in the following corner case: if a bfq_queue, say Q, 1) Is merged with another bfq_queue while it is in a nested soft real-time weight-raising period. The weight-raising state of Q is then saved, and not considered any longer until a split occurs. 2) Is split from the other bfq_queue(s) at a time instant when its soft real-time weight raising is already finished. On the split, while resuming the previous, soft real-time weight-raised state of the bfq_queue Q, BFQ checks whether the current soft real-time weight-raising period is actually over. If so, BFQ switches weight raising off for Q, *without* checking whether the soft real-time period was actually nested in a non-yet-finished interactive weight-raising period. This commit addresses this issue by adding the above missing check in bfq_queue splits, and restoring interactive weight raising if needed. Signed-off-by: Paolo Valente Tested-by: Angelo Ruocco Tested-by: Mirko Montanari commit 2183be4b882745064b07f1b24f69c1f9bd93be0e Author: Paolo Valente Date: Thu Sep 14 05:12:58 2017 -0400 Fix commit "Unnest request-queue and ioc locks from scheduler locks" The commit "Unnest request-queue and ioc locks from scheduler locks" mistakenly removed the setting of the split flag in function bfq_prepare_request. This commit puts this missing instruction back in its place. Signed-off-by: Paolo Valente commit a0d939d228db46463fa532501f21f4cef785d912 Author: Paolo Valente Date: Tue Sep 12 16:45:53 2017 +0200 bfq-mq, bfq-sq: fix wrong init of saved start time for weight raising This commit fixes a bug that causes bfq to fail to guarantee a high responsiveness on some drives, if there is heavy random read+write I/O in the background. More precisely, such a failure allowed this bug to be found [1], but the bug may well cause other yet unreported anomalies. BFQ raises the weight of the bfq_queues associated with soft real-time applications, to privilege the I/O, and thus reduce latency, for these applications. This mechanism is named soft-real-time weight raising in BFQ. A soft real-time period may happen to be nested into an interactive weight raising period, i.e., it may happen that, when a bfq_queue switches to a soft real-time weight-raised state, the bfq_queue is already being weight-raised because deemed interactive too. In this case, BFQ saves in a special variable wr_start_at_switch_to_srt, the time instant when the interactive weight-raising period started for the bfq_queue, i.e., the time instant when BFQ started to deem the bfq_queue interactive. This value is then used to check whether the interactive weight-raising period would still be in progress when the soft real-time weight-raising period ends. If so, interactive weight raising is restored for the bfq_queue. This restore is useful, in particular, because it prevents bfq_queues from losing their interactive weight raising prematurely, as a consequence of spurious, short-lived soft real-time weight-raising periods caused by wrong detections as soft real-time. If, instead, a bfq_queue switches to soft-real-time weight raising while it *is not* already in an interactive weight-raising period, then the variable wr_start_at_switch_to_srt has no meaning during the following soft real-time weight-raising period. Unfortunately the handling of this case is wrong in BFQ: not only the variable is not flagged somehow as meaningless, but it is also set to the time when the switch to soft real-time weight-raising occurs. This may cause an interactive weight-raising period to be considered mistakenly as still in progress, and thus a spurious interactive weight-raising period to start for the bfq_queue, at the end of the soft-real-time weight-raising period. In particular the spurious interactive weight-raising period will be considered as still in progress, if the soft-real-time weight-raising period does not last very long. The bfq_queue will then be wrongly privileged and, if I/O bound, will unjustly steal bandwidth to truly interactive or soft real-time bfq_queues, harming responsiveness and low latency. This commit fixes this issue by just setting wr_start_at_switch_to_srt to minus infinity (farthest past time instant according to jiffies macros): when the soft-real-time weight-raising period ends, certainly no interactive weight-raising period will be considered as still in progress. [1] Background I/O Type: Random - Background I/O mix: Reads and writes - Application to start: LibreOffice Writer in http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.13-IO-Laptop Signed-off-by: Paolo Valente Signed-off-by: Angelo Ruocco Tested-by: Oleksandr Natalenko Tested-by: Lee Tibbert Tested-by: Mirko Montanari commit e3bde8f0e84a0ebe12c9a4dce96688542be33f68 Author: Luca Miccio Date: Wed Sep 13 12:03:56 2017 +0200 bfq-mq, bfq-sq: Disable writeback throttling Similarly to CFQ, BFQ has its write-throttling heuristics, and it is better not to combine them with further write-throttling heuristics of a different nature. So this commit disables write-back throttling for a device if BFQ is used as I/O scheduler for that device. Signed-off-by: Luca Miccio Signed-off-by: Paolo Valente Tested-by: Oleksandr Natalenko commit cd719f5b924fe0a21665a3a3c23490277ca00bad Author: Paolo Valente Date: Thu Aug 31 19:24:26 2017 +0200 doc, block, bfq: fix some typos and stale sentences Signed-off-by: Paolo Valente Reviewed-by: Jeremy Hickman Reviewed-by: Laurentiu Nicola commit 58e6e35084ad36502c70f9090d796c0e5503be84 Author: Paolo Valente Date: Thu Aug 10 08:15:50 2017 +0200 bfq-sq-mq: guarantee update_next_in_service always returns an eligible entity If the function bfq_update_next_in_service is invoked as a consequence of the activation or requeueing of an entity, say E, then it doesn't invoke bfq_lookup_next_entity to get the next-in-service entity. In contrast, it follows a shorter path: if E happens to be eligible (see commit "bfq-sq-mq: make lookup_next_entity push up vtime on expirations" for details on eligibility) and to have a lower virtual finish time than the current candidate as next-in-service entity, then E directly becomes the next-in-service entity. Unfortunately, there is a corner case for which this shorter path makes bfq_update_next_in_service choose a non eligible entity: it occurs if both E and the current next-in-service entity happen to be non eligible when bfq_update_next_in_service is invoked. In this case, E is not set as next-in-service, and, since bfq_lookup_next_entity is not invoked, the state of the parent entity is not updated so as to end up with an eligible entity as the proper next-in-service entity. In this respect, next-in-service is actually allowed to be non eligible while some queue is in service: since no system-virtual-time push-up can be performed in that case (see again commit "bfq-sq-mq: make lookup_next_entity push up vtime on expirations" for details), next-in-service is chosen, speculatively, as a function of the possible value that the system virtual time may get after a push up. But the correctness of the schedule breaks if next-in-service is still a non eligible entity when it is time to set in service the next entity. Unfortunately, this may happen in the above corner case. This commit fixes this problem by making bfq_update_next_in_service invoke bfq_lookup_next_entity not only if the above shorter path cannot be taken, but also if the shorter path is taken but fails to yield an eligible next-in-service entity. Signed-off-by: Paolo Valente commit 4541404040376dd5b2b13af038d8234c023cb08e Author: Paolo Valente Date: Wed Aug 9 22:53:00 2017 +0200 bfq-sq-mq: remove direct switch to an entity in higher class If the function bfq_update_next_in_service is invoked as a consequence of the activation or requeueing of an entity, say E, and finds out that E belongs to a higher-priority class than that of the current next-in-service entity, then it sets next_in_service directly to E. But this may lead to anomalous schedules, because E may happen not be eligible for service, because its virtual start time is higher than the system virtual time for its service tree. This commit addresses this issue by simply removing this direct switch. Signed-off-by: Paolo Valente commit 8f903d7f02daa5758aad99f7a13ba03e3ba0caa9 Author: Paolo Valente Date: Wed Aug 9 22:29:01 2017 +0200 bfq-sq-mq: make lookup_next_entity push up vtime on expirations To provide a very smooth service, bfq starts to serve a bfq_queue only if the queue is 'eligible', i.e., if the same queue would have started to be served in the ideal, perfectly fair system that bfq simulates internally. This is obtained by associating each queue with a virtual start time, and by computing a special system virtual time quantity: a queue is eligible only if the system virtual time has reached the virtual start time of the queue. Finally, bfq guarantees that, when a new queue must be set in service, there is always at least one eligible entity for each active parent entity in the scheduler. To provide this guarantee, the function __bfq_lookup_next_entity pushes up, for each parent entity on which it is invoked, the system virtual time to the minimum among the virtual start times of the entities in the active tree for the parent entity (more precisely, the push up occurs if the system virtual time happens to be lower than all such virtual start times). There is however a circumstance in which __bfq_lookup_next_entity cannot push up the system virtual time for a parent entity, even if the system virtual time is lower than the virtual start times of all the child entities in the active tree. It happens if one of the child entities is in service. In fact, in such a case, there is already an eligible entity, the in-service one, even if it may not be not present in the active tree (because in-service entities may be removed from the active tree). Unfortunately, in the last re-design of the hierarchical-scheduling engine, the reset of the pointer to the in-service entity for a given parent entity--reset to be done as a consequence of the expiration of the in-service entity--always happens after the function __bfq_lookup_next_entity has been invoked. This causes the function to think that there is still an entity in service for the parent entity, and then that the system virtual time cannot be pushed up, even if actually such a no-more-in-service entity has already been properly reinserted into the active tree (or in some other tree if no more active). Yet, the system virtual time *had* to be pushed up, to be ready to correctly choose the next queue to serve. Because of the lack of this push up, bfq may wrongly set in service a queue that had been speculatively pre-computed as the possible next-in-service queue, but that would no more be the one to serve after the expiration and the reinsertion into the active trees of the previously in-service entities. This commit addresses this issue by making __bfq_lookup_next_entity properly push up the system virtual time if an expiration is occurring. Signed-off-by: Paolo Valente commit bc1963f2aff55a460361aabd7e9780947e4f4398 Author: Paolo Valente Date: Wed Aug 9 16:40:39 2017 +0200 bfq-sq: fix commit "Remove all get and put of I/O contexts" in branch bfq-mq The commit "Remove all get and put of I/O contexts" erroneously removed the reset of the field in_service_bic for bfq-sq. This commit re-adds that missing reset. Signed-off-by: Paolo Valente commit e06a9043459091bb3e8afd8e459ebde24f2a8be7 Author: Lee Tibbert Date: Wed Jul 19 10:28:32 2017 -0400 Improve most frequently used no-logging path This patch originated as a fix for compiler unused-variable warnings issued when compiling bfq-mq with logging disabled (both CONFIG_BLK_DEV_IO_TRACE and CONFIG_BFQ_REDIRECT_TO_CONSOLE undefined). It turns out to also have benefits for the bfq-sq path as well. In most performance sensitive production builds blktrace_api logging will probably be turned off, so it is worth making the no-logging path compile without warnings. Any performance benefit is a bonus. Thank you to T. B. on the bfq-iosched@googlegroups.com list for ((void) (bfqq)) simplification/suggestion/improvement. All bugs and unclear descriptions are my own doing. The discussion below is based on the gcc compiler with optimization level of at least 02. Lower optimization levels are unlikely to remove no-op instruction equivalents. Provide three improvements in this likely case. 1) Fix multiple occurrences of an unused-variable warning issued when compiling bfq-mq with no logging. The warning occurred each time the bfq_log_bfqg macro was expanded inside a code block such as the following snippet from block/bfq-sched.c, line 139 and few following, lightly edited for indentation in order to pass checkpatch.pl maximum line lengths. else { struct bfq_group *bfqg = container_of(next_in_service, struct bfq_group, entity); bfq_log_bfqg((struct bfq_data *)bfqg->bfqd, bfqg, "update_next_in_service: chosen this entity"); } Previously bfq-mq.h expanded bfq_log_bfqg to blk_add_trace_msg. When both bfq console logging and blktrace_api logging are disabled, include/linux/blktrace_api expands to do { } while (0), leaving the code block local variable unused. bfq_log_bfqq() had similar behavior but is never called with a potentially unused variable. This patch fixes that macro for consistency. bfq-sq.h (single queue) with blktrace_api enabled, and the bfq console logging macros have code paths which not trigger this warning. kernel.org (4.12 & 4.13) bfq (bfq-iosched.h) could trigger the warning but no code does so now. This patch fixes bfq-iosched.h for consistency. The style above enables a software engineering approach where complex expressions are moved to a local variable before the bfq_log* call. This makes it easier to read the expression and use breakpoints to verify it. bfq-mq uses this approach in several places. New bfq_log* macros are provided for the no-logging case. I touch only the second argument, because current code never uses the local variable approach with the first or other arguments. I tried to balance consistency with simplicity. 2) For bfq-sq, reduce to zero, the number of instructions executed when no logging is configured. No sense marshaling arguments which are never going to be used. On a trial V8R11 builds, this reduced the size of bfq-iosched.o by 14.3 KiB. The size went from 70304 to 55664 bytes. bfq-mq and kernel.org bfq code size does not change because existing macros already optimize to zero bytes when not logging. The current changes maintains consistency with the bfq-sq path and makes the bfq-mq & bfq no-logging paths resistant to future logging path macro changes which might cause generated code. 3) Slightly reduce compile time of all bfq variants by including blktrace_api.h only when it will be used. Signed-off-by: Lee Tibbert commit 17127092e72b700aa6029e734e1d7908b39ab57c Author: Paolo Valente Date: Wed Jul 5 21:08:32 2017 +0200 Add to documentation that bfq-mq and bfq-sq contain last fixes too Signed-off-by: Paolo Valente commit 458fa2c703a168c5975f2b697f05d01d6c5427dc Author: Paolo Valente Date: Wed Jul 5 16:28:00 2017 +0200 bfq-sq: fix prefix of names of cgroups parameters Signed-off-by: Paolo Valente commit 38a61105a4760039d4f1d92c03f57bd71e9503cf Author: Paolo Valente Date: Wed Jul 5 12:43:22 2017 +0200 Add list of bfq instances to documentation Signed-off-by: Paolo Valente commit 8f47efc12f6a4770be14c088d73f9bcaf864aced Author: Paolo Valente Date: Wed Jul 5 12:02:16 2017 +0200 Port of "blk-mq-sched: unify request prepare methods" This patch makes sure we always allocate requests in the core blk-mq code and use a common prepare_request method to initialize them for both mq I/O schedulers. For Kyber and additional limit_depth method is added that is called before allocating the request. Also because none of the intializations can really fail the new method does not return an error - instead the bfq finish method is hardened to deal with the no-IOC case. Last but not least this removes the abuse of RQF_QUEUE by the blk-mq scheduling code as RQF_ELFPRIV is all that is needed now. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe commit 8495d42c1117e05c59c563d28b1c981786300d70 Author: Paolo Valente Date: Wed Jul 5 11:54:57 2017 +0200 Port of "bfq-iosched: fix NULL ioc check in bfq_get_rq_private" icq_to_bic is a container_of operation, so we need to check for NULL before it. Also move the check outside the spinlock while we're at it. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe commit 87517a075c5851c645fcfbb721cb48778c193781 Author: Paolo Valente Date: Wed Jul 5 11:48:17 2017 +0200 Port of "blk-mq-sched: unify request finished methods" No need to have two different callouts of bfq vs kyber. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe commit b0a371afc200b0513b4e9c0166dc220f8c9fd6fe Author: Paolo Valente Date: Sat Jun 17 11:18:11 2017 +0200 bfq-mq: fix macro name in conditional invocation of policy_unregister This commit fixes the name of the macro in the conditional group that invokes blkcg_policy_unregister in bfq_exit for bfq-mq. Because of this error, blkcg_policy_unregister was never invoked. Signed-off-by: Paolo Valente commit 914c83280e3d65940dee11e5f1a193d4ea624cfc Author: Paolo Valente Date: Mon May 15 22:25:03 2017 +0200 block, bfq-mq: access and cache blkg data only when safe In blk-cgroup, operations on blkg objects are protected with the request_queue lock. This is no more the lock that protects I/O-scheduler operations in blk-mq. In fact, the latter are now protected with a finer-grained per-scheduler-instance lock. As a consequence, although blkg lookups are also rcu-protected, blk-mq I/O schedulers may see inconsistent data when they access blkg and blkg-related objects. BFQ does access these objects, and does incur this problem, in the following case. The blkg_lookup performed in bfq_get_queue, being protected (only) through rcu, may happen to return the address of a copy of the original blkg. If this is the case, then the blkg_get performed in bfq_get_queue, to pin down the blkg, is useless: it does not prevent blk-cgroup code from destroying both the original blkg and all objects directly or indirectly referred by the copy of the blkg. BFQ accesses these objects, which typically causes a crash for NULL-pointer dereference of memory-protection violation. Some additional protection mechanism should be added to blk-cgroup to address this issue. In the meantime, this commit provides a quick temporary fix for BFQ: cache (when safe) blkg data that might disappear right after a blkg_lookup. In particular, this commit exploits the following facts to achieve its goal without introducing further locks. Destroy operations on a blkg invoke, as a first step, hooks of the scheduler associated with the blkg. And these hooks are executed with bfqd->lock held for BFQ. As a consequence, for any blkg associated with the request queue an instance of BFQ is attached to, we are guaranteed that such a blkg is not destroyed, and that all the pointers it contains are consistent, while that instance is holding its bfqd->lock. A blkg_lookup performed with bfqd->lock held then returns a fully consistent blkg, which remains consistent until this lock is held. In more detail, this holds even if the returned blkg is a copy of the original one. Finally, also the object describing a group inside BFQ needs to be protected from destruction on the blkg_free of the original blkg (which invokes bfq_pd_free). This commit adds private refcounting for this object, to let it disappear only after no bfq_queue refers to it any longer. This commit also removes or updates some stale comments on locking issues related to blk-cgroup operations. Reported-by: Tomas Konir Reported-by: Lee Tibbert Reported-by: Marco Piazza Signed-off-by: Paolo Valente Tested-by: Tomas Konir Tested-by: Lee Tibbert Tested-by: Marco Piazza commit 73d28b70bac2ae868db6e9b6fc3a94d0f5ba4b4b Author: Paolo Valente Date: Fri May 12 11:56:13 2017 +0200 Add tentative extra tests on groups, reqs and queues Signed-off-by: Paolo Valente commit b0a807ebd2820afa508f81aedef3c91be5fefb51 Author: Paolo Valente Date: Fri May 12 09:51:18 2017 +0200 Change cgroup params prefix to bfq-mq for bfq-mq Signed-off-by: Paolo Valente commit 7e4ab2d9d9ff45075d5b0db698c3ccde4fea9426 Author: Paolo Valente Date: Wed Mar 29 18:55:30 2017 +0200 Fix wrong unlikely Signed-off-by: Paolo Valente commit c8e26cadb7d6d43d6fc81242983da153221edfb3 Author: Paolo Valente Date: Wed Mar 29 18:41:46 2017 +0200 BUGFIX: Remove unneeded and deadlock-causing lock in request_merged Signed-off-by: Paolo Valente commit 54609fee9fa6cc6c48e11530f837d70b75e8761d Author: Paolo Valente Date: Fri Mar 17 06:15:18 2017 +0100 Remove all get and put of I/O contexts When a bfq queue is set in service and when it is merged, a reference to the I/O context associated with the queue is taken. This reference is then released when the queue is deselected from service or split. More precisely, the release of the reference is postponed to when the scheduler lock is released, to avoid nesting between the scheduler and the I/O-context lock. In fact, such nesting would lead to deadlocks, because of other code paths that take the same locks in the opposite order. This postponing of I/O-context releases does complicate code. This commit addresses this issue by modifying involved operations in such a way to not need to get the above I/O-context references any more. Then it also removes any get and release of these references. Signed-off-by: Paolo Valente commit 65bf72fd0dd7ce4982d3b72a08b7a517f344a963 Author: Paolo Valente Date: Sat Feb 25 17:38:05 2017 +0100 Complete support for cgroups This commit completes cgroups support for bfq-mq. In particular, it deals with a sort of circular dependency introduced in blk-mq: the function blkcg_activate_policy, invoked during scheduler initialization, triggers the invocation of the has_work scheduler hook (before the init function is finished). To adress this issue, this commit moves the invocation of blkcg_activate_policy after the initialization of all the fields that could be initialized before invoking blkcg_activate_policy itself. This enables has_work to correctly return false, and thus to prevent the blk-mq stack from invoking further scheduler hooks before the init function is finished. Signed-off-by: Paolo Valente commit 33ee96a13e87d1fe33aa2f777a5a63b894fdc3c6 Author: Paolo Valente Date: Fri Feb 17 14:28:02 2017 +0100 TESTING: Check wrong invocation of merge and put_rq_priv functions Check that merge functions are not invoked on requests queued in the dispatch queue, and that neither put_rq_private is invoked on these requests if, in addition, they have not passed through get_rq_private. Signed-off-by: Paolo Valente commit 02cf428a72f7e95cdb054c7685f7bcc9836179d9 Author: Paolo Valente Date: Fri Mar 3 09:39:35 2017 +0100 Add checks and extra log messages - Part III Signed-off-by: Paolo Valente commit d3a27cdcdd2f6d8163f7b7e0e25cafdb53ca0604 Author: Paolo Valente Date: Wed Feb 22 11:30:01 2017 +0100 Fix unbalanced increment of rq_in_driver Signed-off-by: Paolo Valente commit aa928ced42c4c44d6bf1fc4f7bb35a232b81e9d3 Author: Paolo Valente Date: Fri Mar 3 09:31:14 2017 +0100 Add checks and extra log messages - Part II Signed-off-by: Paolo Valente commit acff396266844c50079032f98c2a4cd44d9d336b Author: Paolo Valente Date: Tue Feb 21 10:26:22 2017 +0100 Unnest request-queue and ioc locks from scheduler locks In some bio-merging functions, the request-queue lock needs to be taken, to lookup for the bic associated with the process that issued the bio that may need to be merged. In addition, put_io_context must be invoked in some other functions, and put_io_context may cause the lock of the involved ioc to be taken. In both cases, these extra request-queue or ioc locks are taken, or might be taken, while the scheduler lock is being held. In this respect, there are other code paths, in part external to bfq-mq, in which the same locks are taken (nested) in the opposite order, i.e., it is the scheduler lock to be taken while the request-queue or the ioc lock is being held. This leads to circular deadlocks. This commit addresses this issue by modifying the logic of the above functions, so as to let the lookup and put_io_context be performed, and thus the extra locks be taken, outside the critical sections protected by the scheduler lock. Signed-off-by: Paolo Valente commit 8c9eaa76afb170bbcc674f33954dfd2ddcff715a Author: Paolo Valente Date: Tue Feb 7 15:14:29 2017 +0100 bfq-mq: execute exit_icq operations immediately Exploting Omar's patch that removes the taking of the queue lock in put_io_context_active, this patch moves back the operation of the bfq_exit_icq hook from a deferred work to the body of the function. Signed-off-by: Paolo Valente commit ff1636fc532b0f2e5e209b807b43f515723b7bcf Author: Paolo Valente Date: Thu Feb 9 10:36:27 2017 +0100 Add lock check in bfq_allow_bio_merge Signed-off-by: Paolo Valente commit ac1ad8483b31b63e2e27fe4ee868db9a4cd9b6a3 Author: Paolo Valente Date: Fri Mar 3 08:52:40 2017 +0100 Add checks and extra log messages - Part I Signed-off-by: Paolo Valente commit 3e34c8fae17ca0cf6466af688a2c5df053d23427 Author: Paolo Valente Date: Tue Dec 20 09:07:19 2016 +0100 Modify interface and operation to comply with blk-mq-sched As for modifications of the operation, the major changes are the introduction of a scheduler lock, and the moving to deferred work of the body of the hook exit_icq. The latter change has been made to avoid deadlocks caused by the combination of the following facts: 1) such a body takes the scheduler lock, and, if not deferred, 2) it does so from inside the exit_icq hook, which is invoked with the queue lock held, and 3) there is at least one code path, namely that starting from bfq_bio_merge, which takes these locks in the opposite order. Signed-off-by: Paolo Valente commit 501706cb9a3c4d749afe16ce6132b380ff4ef700 Author: Paolo Valente Date: Wed Jan 18 11:42:22 2017 +0100 Embed bfq-ioc.c and add locking on request queue The version of bfq-ioc.c for bfq-iosched.c is not correct any more for bfq-mq, because, in bfq-mq, the request queue lock is not being held when bfq_bic_lookup is invoked. That function must then take that look on its own. This commit removes the inclusion of bfq-ioc.c, copies the content of bfq-ioc.c into bfq-mq-iosched.c, and adds the grabbing of the lock. Signed-off-by: Paolo Valente commit 6f8dc32a599289eba376311fe013619bdc9e73bb Author: Paolo Valente Date: Sat Jan 21 12:41:14 2017 +0100 Move thinktime from bic to bfqq Prep change to make it possible to protect this field with a scheduler lock. Signed-off-by: Paolo Valente commit 4f8ced3d9cae342f91b448829eb2cc120be2b0ed Author: Paolo Valente Date: Mon Dec 19 18:11:33 2016 +0100 Copy header file bfq.h as bfq-mq.h This commit introduces the header file bfq-mq.h, that will play for bfq-mq-iosched.c the same role that bfq.h plays for bfq-iosched.c. For the moment, the file bfq-mq.h is just a copy of bfq.h. Signed-off-by: Paolo Valente commit 19e675e920ac94f140b433a663e6006e805a9318 Author: Paolo Valente Date: Fri Jan 20 09:18:25 2017 +0100 Increase max policies for io controller To let bfq-mq policy be plugged too (however cgroups suppport is not yet functional in bfq-mq). Signed-off-by: Paolo Valente commit 9bf3d10b56803d274f34f66883daa14036d574f6 Author: Paolo Valente Date: Mon Dec 19 17:13:39 2016 +0100 Add config and build bits for bfq-mq-iosched Signed-off-by: Paolo Valente commit 2fc2a8b2f31fa92ad283daaba9327d2b647619e4 Author: Paolo Valente Date: Mon Dec 19 16:59:33 2016 +0100 FIRST BFQ-MQ COMMIT: Copy bfq-sq-iosched.c as bfq-mq-iosched.c This commit introduces bfq-mq-iosched.c, the main source file that will contain the code of bfq for blk-mq. I name tentatively bfq-mq this version of bfq. For the moment, the file bfq-mq-iosched.c is just a copy of bfq-sq-iosched.c, i.e, of the main source file of bfq for blk. Signed-off-by: Paolo Valente commit 227fb91e4fa5345d6c7e4e733f12a9c6d03afbac Author: Paolo Valente Date: Thu May 4 10:53:43 2017 +0200 block, bfq: improve and refactor throughput-boosting logic When a queue associated with a process remains empty, there are cases where throughput gets boosted if the device is idled to await the arrival of a new I/O request for that queue. Currently, BFQ assumes that one of these cases is when the device has no internal queueing (regardless of the properties of the I/O being served). Unfortunately, this condition has proved to be too general. So, this commit refines it as "the device has no internal queueing and is rotational". This refinement provides a significant throughput boost with random I/O, on flash-based storage without internal queueing. For example, on a HiKey board, throughput increases by up to 125%, growing, e.g., from 6.9MB/s to 15.6MB/s with two or three random readers in parallel. This commit also refactors the code related to device idling, for the following reason. Finding the change that provides the above large improvement has been slightly more difficult than it had to be, because the logic that decides whether to idle the device is still scattered across three functions. Almost all of the logic is in the function bfq_bfqq_may_idle, but (1) part of the decision is made in bfq_update_idle_window, and (2) the function bfq_bfqq_must_idle may switch off idling regardless of the output of bfq_bfqq_may_idle. In addition, both bfq_update_idle_window and bfq_bfqq_must_idle make their decisions as a function of parameters that are used, for similar purposes, also in bfq_bfqq_may_idle. This commit addresses this issue by moving all the logic into bfq_bfqq_may_idle. Signed-off-by: Paolo Valente Signed-off-by: Luca Miccio commit 1bc3cb446d8edc76eaa94c81b07d8010dbea795d Author: Paolo Valente Date: Fri Jul 28 21:09:51 2017 +0200 block, bfq: consider also in_service_entity to state whether an entity is active Groups of BFQ queues are represented by generic entities in BFQ. When a queue belonging to a parent entity is deactivated, the parent entity may need to be deactivated too, in case the deactivated queue was the only active queue for the parent entity. This deactivation may need to be propagated upwards if the entity belongs, in its turn, to a further higher-level entity, and so on. In particular, the upward propagation of deactivation stops at the first parent entity that remains active even if one of its child entities has been deactivated. To decide whether the last non-deactivation condition holds for a parent entity, BFQ checks whether the field next_in_service is still not NULL for the parent entity, after the deactivation of one of its child entity. If it is not NULL, then there are certainly other active entities in the parent entity, and deactivations can stop. Unfortunately, this check misses a corner case: if in_service_entity is not NULL, then next_in_service may happen to be NULL, although the parent entity is evidently active. This happens if: 1) the entity pointed by in_service_entity is the only active entity in the parent entity, and 2) according to the definition of next_in_service, the in_service_entity cannot be considered as next_in_service. See the comments on the definition of next_in_service for details on this second point. Hitting the above corner case causes crashes. To address this issue, this commit: 1) Extends the above check on only next_in_service to controlling both next_in_service and in_service_entity (if any of them is not NULL, then no further deactivation is performed) 2) Improves the (important) comments on how next_in_service is defined and updated; in particular it fixes a few rather obscure paragraphs Reported-by: Eric Wheeler Reported-by: Rick Yiu Reported-by: Tom X Nguyen Signed-off-by: Paolo Valente Tested-by: Eric Wheeler Tested-by: Rick Yiu Tested-by: Laurentiu Nicola Tested-by: Tom X Nguyen commit 089cdf890a512f6a4add1088a3484f0a6d8fee3d Author: Paolo Valente Date: Fri Jul 21 12:08:57 2017 +0200 block, bfq: reset in_service_entity if it becomes idle BFQ implements hierarchical scheduling by representing each group of queues with a generic parent entity. For each parent entity, BFQ maintains an in_service_entity pointer: if one of the child entities happens to be in service, in_service_entity points to it. The resetting of these pointers happens only on queue expirations: when the in-service queue is expired, i.e., stops to be the queue in service, BFQ resets all in_service_entity pointers along the parent-entity path from this queue to the root entity. Functions handling the scheduling of entities assume, naturally, that in-service entities are active, i.e., have pending I/O requests (or, as a special case, even if they have no pending requests, they are expected to receive a new request very soon, with the scheduler idling the storage device while waiting for such an event). Unfortunately, the above resetting scheme of the in_service_entity pointers may cause this assumption to be violated. For example, the in-service queue may happen to remain without requests because of a request merge. In this case the queue does become idle, and all related data structures are updated accordingly. But in_service_entity still points to the queue in the parent entity. This inconsistency may even propagate to higher-level parent entities, if they happen to become idle as well, as a consequence of the leaf queue becoming idle. For this queue and parent entities, scheduling functions have an undefined behaviour, and, as reported, may easily lead to kernel crashes or hangs. This commit addresses this issue by simply resetting the in_service_entity field also when it is detected to point to an entity becoming idle (regardless of why the entity becomes idle). Reported-by: Laurentiu Nicola Signed-off-by: Paolo Valente Tested-by: Laurentiu Nicola commit a2729aa74adfbefb0fdf8872f263355c2cc171e0 Author: Paolo Valente Date: Thu Jul 20 10:46:39 2017 +0200 Add extra checks related to entity scheduling - extra checks related to ioprioi-class changes - specific check on st->idle in __bfq_requeue_entity Signed-off-by: Paolo Valente commit e5a5cb2a7b1c81edb6e22ccd5258bf2ee665f775 Author: Paolo Valente Date: Tue Apr 7 13:39:12 2015 +0200 Add BFQ-v8r12 This commit is the result of the following operations. 1. The squash of all the commits between "block: cgroups, kconfig, build bits for BFQ-v7r11-4.5.0" and BFQ-v8r12 in the branch bfq-mq-v8-v4.11 2. The renaming of two files (block/bfq-cgroup.c -> block/bfq-cgroup-included.c and block/bfq-iosched.c -> block/bfq-sq-iosched.c) and of one option (CONFIG_BFQ_GROUP_IOSCHED -> CONFIG_BFQ_SQ_GROUP_IOSCHED), to avoid name clashes. These name clashes are due to the presence of bfq in mainline from 4.12. 3. The modification of block/Makefile and block/Kconfig.iosched to comply with the above renaming. Signed-off-by: Mauro Andreolini Signed-off-by: Arianna Avanzini Signed-off-by: Linus Walleij Signed-off-by: Paolo Valente commit 10dacf15fd2979d6022e13923bed8f622bb1f534 Author: Alfred Chen Date: Fri May 25 10:50:49 2018 +0800 Tag PDS 0.98q commit e7350b10b469086f745c33005343216e0640791b Author: Alfred Chen Date: Mon Jun 4 16:22:14 2018 +0800 pds: [Sync] e97a90f7069b sched/cpufreq: Rate limits for SCHED_DEADLINE commit 0610ca6b6044573786ed8daebdc470ef000f9586 Author: Alfred Chen Date: Wed May 23 17:02:26 2018 +0800 pds: [Sync] b5bf9a90bbeb sched/core: Introduce set_special_state() commit 4019343da28444f5f52b8a560dcd77dba74154b1 Author: Alfred Chen Date: Wed May 23 16:50:11 2018 +0800 pds: [Sync] 85f1abe0019f kthread, sched/wait: Fix kthread_parkme() completion issue commit fb93f763635c53511c6c1085a0df50ce437eaf95 Author: Alfred Chen Date: Wed May 23 16:39:45 2018 +0800 pds: [Sync] 3eda69c92d47 kernel/fork.c: detect early free of a live mm commit ada8558c3f9a4f784b55bc807fe800da7a2eef60 Author: Alfred Chen Date: Wed May 23 16:37:51 2018 +0800 pds: [Sync] b720342849fe sched/core: Update preempt_notifier_key to modern API commit f85e5c7bd9ff8378d3bca7d78b3749bb48435f34 Author: Alfred Chen Date: Wed May 23 14:40:36 2018 +0800 pds: [Sync] 14a7405b2e81 sched/core: Undefine tracepoint creation at the end of core.c commit bbd1fddca534dc307250f225e6d914636099d9d9 Author: Alfred Chen Date: Wed May 23 14:37:14 2018 +0800 pds: [Sync] 97fb7a0a8944 sched: Clean up and harmonize the coding style of the scheduler code base commit dd8ab4d1faa0b310ed5ddcfb943b19e7c878e544 Author: Alfred Chen Date: Wed May 23 14:35:00 2018 +0800 pds: [Sync] dcdedb24159b sched/nohz: Remove the 1 Hz tick code commit 859089b8587c21063c16a45d4e928e3b15577bc7 Author: Alfred Chen Date: Wed May 23 14:30:50 2018 +0800 pds: [Sync] 325ea10c0809 sched/headers: Simplify and clean up header usage in the scheduler commit b4e13c6b3baaab3a8c454db5a8881874b089dce2 Author: Alfred Chen Date: Wed May 23 10:55:06 2018 +0800 pds: [Sync] d84b31313ef8 sched/isolation: Offload residual 1Hz scheduler tick commit 774164497959dc15e3bbf389b7c3a348a487fcc2 Author: Alfred Chen Date: Tue May 22 13:50:12 2018 +0800 pds: [Sync] 7d4dd4f159b9 sched: add do_sched_yield() helper; remove in-kernel call to sched_yield() commit b2af58581a90f86e05e84ec83cf4353a64f6b99e Author: Alfred Chen Date: Mon May 21 15:37:43 2018 +0800 pds: [Sync] 77a021be383e sched/core: Rename init_rq_hrtick() to hrtick_rq_init() commit 61efb4177f4d8ad2895f81fb78d148cdca9c0cc2 Author: Alfred Chen Date: Sun May 20 22:37:03 2018 +0800 pds: Fix none return in pds_trigger_balance() Fix none return in pds_trigger_balance() when SMT not defined. commit 3a12c070dea6d88956135447cef76070655249ae Author: Alfred Chen Date: Sun May 13 20:28:01 2018 +0800 Tag PDS 0.98p commit ac7d10e961f9e6c19b7e1a83d212c75d944d0e4c Author: Alfred Chen Date: Sun May 13 20:26:52 2018 +0800 pds: 32ms balance interval. commit edaff1479a26d4e4b1bd03f568ae935c41e5792b Author: Alfred Chen Date: Sun May 13 17:26:26 2018 +0800 pds: Balance optimization. commit d04df9e55e8a28fd8aa04d425520d812c1928a6e Author: Alfred Chen Date: Thu May 3 15:14:07 2018 +0800 pds: Instroduce per cpu sched_cpu_affinity_chk_masks. commit afa12dfdfea100ba211c0b6c113e1130f90c605b Author: Alfred Chen Date: Thu May 3 15:13:02 2018 +0800 pds: Extract update_rq_clock() from activate_task(). commit 46e9b00d029da0c347140939e86fa15943d89b48 Author: Alfred Chen Date: Thu May 3 15:11:25 2018 +0800 pds: Instroduce per cpu has_smt_sibling. commit 17a9a2eac0b277651434483d54b5680e1089665b Author: Alfred Chen Date: Thu May 3 15:01:01 2018 +0800 pds: Check IDLE tasks suitable to run as NORMAL in ttwu. commit 1e49d09ad722910950b2c34774f2a5397a3700a2 Author: Alfred Chen Date: Thu May 3 11:04:04 2018 +0800 Tag PDS 0.98o commit e057d4051181852951c3537e940a0465ee266ca0 Author: Alfred Chen Date: Tue Apr 24 14:54:07 2018 +0800 pds: Remove addtional cpu ative check in rebalance. commit 523a96a7601a224ded267e2f69b5ee71a68a7a7f Author: Alfred Chen Date: Fri Apr 20 15:23:58 2018 +0800 pds: Remove unused sched_cpu_affinity_llc_end_masks. commit 941aa89178bf74e7d35cd2f84dd0879f05862d70 Author: Alfred Chen Date: Thu Apr 19 15:02:37 2018 +0800 pds: Fix a bug in get_nohz_timer_target(). commit 6420cadf40a11bf556bcf1b48dac846267b85ec1 Author: Alfred Chen Date: Thu Apr 19 14:27:20 2018 +0800 pds: Remove unnecessary task prio update in activate_task(). commit 08028dd5d40885ca7923f29646143bfcf4ddeb71 Author: Alfred Chen Date: Thu Apr 19 13:47:46 2018 +0800 pds: Remove sleep profiling. Current sleep profiling is not accurate. commit 2cf373b7e73403dc7f25811928070b5215f6ea5c Author: Alfred Chen Date: Wed Apr 18 16:46:36 2018 +0800 pds: Optimize cpumask usage. commit 9c98903bfa902ef9885148c139d0ac1ca69b20f0 Author: Alfred Chen Date: Wed Apr 18 15:23:06 2018 +0800 pds: Optimze WARN_ONCE format parameter usage. commit bbc18bc49bd4de656af6e60e51ec0df56590a810 Author: Alfred Chen Date: Wed Apr 18 15:04:13 2018 +0800 pds: Code cleanup. commit 424c62f001f847d5883273a3be74bb1fbd862e2b Author: Alfred Chen Date: Wed Apr 18 14:54:27 2018 +0800 pds: inline enqueue_task() and dequeue_task(). commit 2d6ff04e1d238450e508178178b4bb4e878964a4 Author: Alfred Chen Date: Wed Apr 18 15:05:50 2018 +0800 pds: Optimize enqueue_task(). commit 938dc4cb979c5cee2c26546953766165fb82a564 Author: Alfred Chen Date: Fri Apr 13 21:57:27 2018 +0800 Tag PDS 0.98n commit 1e9462e97f95b03017c68d8ec89390f508853b76 Author: Alfred Chen Date: Thu Apr 12 12:47:31 2018 +0800 pds: Optimize pds_load_balance(). commit 5b2af92f7a48045d30bfea4e08b65ebf29243a36 Author: Alfred Chen Date: Wed Apr 11 19:45:11 2018 +0800 pds: Code cleanup. commit 86cacd39b8ad6963205f8df548de90d75ff88a2d Author: Alfred Chen Date: Wed Apr 11 13:55:44 2018 +0800 pds: Optimize scheduler_tick() and pds_sg_balance(). commit 0e808a62966848a053803b6a178a391c04b63fca Author: Alfred Chen Date: Sun Apr 8 16:04:50 2018 +0800 pds: Migrate max SCHED_RQ_NR_MIGRATION tasks to empty rq at a time. commit 121e6887db0b378e441c360e47a9c07fbffda3aa Author: Alfred Chen Date: Fri Mar 30 21:54:05 2018 +0800 Tag PDS 0.98m commit be5c84ad2148ce1c064bbf8f7fb85ea7ae906285 Author: Alfred Chen Date: Fri Mar 30 09:00:51 2018 +0800 pds: Fix likely/unlike usage. commit 71059916a5a7e64c113d9fa8906eebc87e1e719d Author: Alfred Chen Date: Wed Mar 28 14:44:28 2018 +0800 pds: Code cleanup. commit 8e89c25e6cc0cb61ec03d0e6857a83fd29db6082 Author: Alfred Chen Date: Wed Mar 28 13:45:17 2018 +0800 pds: Refine rq_best_pending_task(). commit 28d2aebb20d14fcea35b91e9fa73fa028b30ca28 Author: Alfred Chen Date: Wed Mar 28 08:20:12 2018 +0800 pds: Refine sched_init_topology_cpumask(). commit 1c3e5e5e148b0daac948a0336ec90eea21fb24f0 Author: Alfred Chen Date: Tue Mar 27 23:21:34 2018 +0800 pds: Accurate preempt for RT tasks. commit 4c35578104465a929098fb066405c724de0cd221 Author: Alfred Chen Date: Sat Mar 24 18:15:36 2018 +0800 pds: Refine best_mask_cpu(). commit 5b6ba65b8786ae4a3f059b453f37367f8e45352f Author: Alfred Chen Date: Sat Mar 24 16:31:29 2018 +0800 pds: Remove cpu scaling interfaces. commit 0580c6afbfbd3def6523e47d601efb53c44b1e3a Author: Alfred Chen Date: Sat Mar 24 07:18:08 2018 +0800 pds: Unify 32/64bits handing in task_preemptible_rq(). commit 7b9ceb91436aa6be6a1772e1fd6494d0a2141253 Author: Alfred Chen Date: Sat Mar 24 15:24:32 2018 +0800 Tag PDS 0.98l commit 9ea040d7001960bf8b2b0e941d40a1ef0a35c288 Author: Alfred Chen Date: Fri Mar 23 16:37:51 2018 +0800 pds: [Sync] 269d599271fa sched/core: Fix DEBUG_SPINLOCK annotation for rq->lock commit 8a6c9e6ea5de90849a8343c597bdf49c0822ee7c Author: Alfred Chen Date: Fri Mar 23 16:23:03 2018 +0800 pds: [Sync] 4de373a12f3c cpumask: make cpumask_size() return "unsigned int" commit 3f91e0f5f6a57a1ce70049c378e61900ce5f6412 Author: Alfred Chen Date: Fri Mar 23 16:20:50 2018 +0800 pds: [Sync] 32e839dda3ba sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS commit bc37e8b727847ab568cd8453f32923dafb99022c Author: Alfred Chen Date: Fri Mar 23 16:04:55 2018 +0800 pds: [Sync] b85c8b71bf8d sched/core: Optimize ttwu_stat() commit 61ba65ae4f6c6d6172dae1f59438506899dbb8d6 Author: Alfred Chen Date: Fri Mar 23 15:55:04 2018 +0800 pds: [Sync] 70216e18e519 membarrier: Provide core serializing command, *_SYNC_CORE commit 04965a2717adb63023c8be2615d85899b6640ddf Author: Alfred Chen Date: Fri Mar 23 15:50:08 2018 +0800 pds: [Sync] 306e060435d7 membarrier: Document scheduler barrier requirements commit 96e2855e1df6acdafebe7cf41c6308e3a34ccfae Author: Alfred Chen Date: Fri Mar 23 14:30:33 2018 +0800 pds: [Sync] 3ccfebedd8cf powerpc, membarrier: Skip memory barrier in switch_mm() commit e99a57fdb99512ec4916674cdff513e13f3d3dc1 Author: Alfred Chen Date: Fri Mar 23 14:24:20 2018 +0800 pds: [Sync] a0982dfa03ef sched: Stop resched_cpu() from sending IPIs to offline CPUs commit 3f90fe54d743214f2727e75f982c8f7576e5b129 Author: Alfred Chen Date: Fri Mar 23 13:44:09 2018 +0800 pds: [Sync] 34be39305a77 sched/deadline: Implement "runtime overrun signal" support commit da1a7bd4a1c0a8decbc77b61fadddcc2864ca05e Author: Alfred Chen Date: Fri Mar 23 12:40:54 2018 +0800 pds: [Sync] 794a56ebd9a5 sched/cpufreq: Change the worker kthread to SCHED_DEADLINE commit 6cb681ef34d72b8b9435f8e6800476cd75db7fa6 Author: Alfred Chen Date: Fri Mar 23 11:11:50 2018 +0800 pds: [Sync] e0367b12674b sched/deadline: Move CPU frequency selection triggering points commit dc26e6b81e04b8594043efa209afd0bd9b6e0b64 Author: Alfred Chen Date: Fri Mar 23 10:45:53 2018 +0800 pds: [Sync] 31cb1bc0dc94 sched/core: Rework and clarify prepare_lock_switch() commit 1eec5d2a99c1d895a2bbbb847bb63935221e882f Author: Alfred Chen Date: Thu Feb 15 23:12:10 2018 +0800 Tag PDS 0.98k commit a2d971bc67bda70288f3b5c6c78338b41b1b9a7d Author: Alfred Chen Date: Wed Feb 14 17:28:54 2018 +0800 pds: Remove unused variables in task_struct. commit aa9c05bf4d5bfb2e2517c85eb6f2911e48673d52 Author: Alfred Chen Date: Wed Feb 14 11:05:04 2018 +0800 pds: Remove unused rq->last_switch commit 9494c47aee9267797b70b1359e7242b7c0c6ddf1 Author: Alfred Chen Date: Thu Feb 8 14:29:29 2018 +0800 pds: Rework prio2deadline routines. commit fbab8b32844583d919e9f49e7d6d5f48e7eb278c Author: Alfred Chen Date: Thu Feb 8 14:09:21 2018 +0800 pds: inline check_preempt_curr(). commit 655ee94eafb6db1cfaa290be6e581a50ee704f4c Author: Alfred Chen Date: Wed Feb 7 22:29:18 2018 +0800 pds: returns cpu instead of rq in task_preemptible_rq() and select_task_rq() commit 66b407069943c7206a3033c7a7a31d8b1012c22e Author: Alfred Chen Date: Thu Jan 18 14:19:14 2018 +0800 Tag PDS 0.98j commit 73183a24cf6b823c7688f275d3cbce335ef7d9bb Author: Alfred Chen Date: Tue Jan 30 17:23:32 2018 +0800 pds: [Sync] c96f5471ce7d delayacct: Account blkio completion on the correct task commit 18c453bacc3dc54598eb42c7847c19b171c12992 Author: Alfred Chen Date: Fri Jan 12 15:00:10 2018 +0800 pds: [Sync] sched_rr_get_interval commit c95488f734b602d017f8b45c2137311680b6ae88 Author: Alfred Chen Date: Thu Jan 4 15:01:53 2018 +0800 pds: [Sync] ff0d4a9dc16b sched/rt: Add a helper to test for a RT task commit 7c9e176bc86ff6e45e39d26c0b1bd1d17a41d85b Author: Alfred Chen Date: Thu Jan 4 14:57:09 2018 +0800 pds: [Sync] d2cc5ed69490 cpuacct: Introduce cgroup_account_cputime[_field]() commit 6bcba010d2cbe962c20a167b89adf8e90b8bcd83 Author: Alfred Chen Date: Thu Jan 4 13:49:17 2018 +0800 pds: [Sync] sched/isolation commit f98c5b1003b77959211e2facc7db28d1d2156b05 Author: Alfred Chen Date: Thu Jan 4 12:28:06 2018 +0800 pds: [Sync] 0032f4e88976 rcutorture: Dump writer stack if stalled commit d41463c1bea88fa9b8b7b004af9152fcbba0ef76 Author: Alfred Chen Date: Thu Jan 4 12:26:29 2018 +0800 pds: [Sync] f79c3ad61896 sched,rcu: Make cond_resched() provide RCU quiescent state commit 3f5527c9951781d12d2dd6514726cbb93180a7da Author: Alfred Chen Date: Mon Jan 15 08:45:12 2018 +0800 Tag PDS 0.98i commit dc3f241a698a6f213afca86ae6e395e27ed68d25 Author: Alfred Chen Date: Mon Jan 15 08:44:23 2018 +0800 pds: 16ms dispersed balance interval. commit 9ca0db44bdba16eeabe18141932fe5e0e496386a Author: Alfred Chen Date: Thu Jan 4 10:16:12 2018 +0800 pds: Set default yeild_type to 1 and remove yield_to() support. commit aa811d7095ff48434b05ac94dd9fc35c3281c3ee Author: Alfred Chen Date: Wed Jan 3 11:00:29 2018 +0800 Revert "pds: Remove yield support." This reverts commit 493d8652b2dde694ab3d7f3abbb2047d79aa33f3. commit 694b88b4cff08dfdb7ed9dd707631a354e638b00 Author: Alfred Chen Date: Sat Dec 23 09:20:12 2017 +0800 Tag PDS 0.98h commit 6490281ab0f8120be6700382e0b139d9e09e2226 Author: Alfred Chen Date: Fri Dec 22 14:05:33 2017 +0800 pds: Fix error: implicit declaration of function 'hrtick_start' There is error: implicit declaration of function 'hrtick_start' when SCHED_HRTICK is not defined. commit 8543ec1501b8b3e4fe55d04463c61267519dc33b Author: Alfred Chen Date: Fri Dec 22 14:02:46 2017 +0800 pds: Fix warning: 'set_rq_offline' defined but not used commit dbc42464ca28cd76b749fef6a5e1bb17f06d1700 Author: Alfred Chen Date: Fri Dec 22 12:54:28 2017 +0800 pds: Fix undefined error for some architectures. For PowerPC architecture, cpu_coregroup_mask() is not defined. This fix such errors for some architectures which short of topology api defined. commit a0d67f70eae2156f0f8070c4d8b60ea6931d31d6 Author: Alfred Chen Date: Mon Nov 27 14:14:03 2017 +0800 pds: Fix UP compilation error. commit db7986cea1dc75b03cd193cd9b1039895594ad44 Author: Alfred Chen Date: Fri Nov 24 15:15:45 2017 +0800 Tag PDS 0.98g commit 078b01d51ab82e435a4ac4a035ccb17598be2fab Author: Alfred Chen Date: Fri Nov 24 15:13:21 2017 +0800 pds: Remove update_rq_clock() in hrtick(). Remove update_rq_clock() in hrtick() as it is going to reschedule anyway. commit d7db9a0ccc8ba221522953486681006989363508 Author: Alfred Chen Date: Fri Nov 17 18:21:41 2017 +0800 pds: Fix rq->online is default false for cpu 0. commit 7cbc1aa6bfc7be84e05b9de7cf3412f9c03fed41 Author: Alfred Chen Date: Thu Nov 16 21:44:51 2017 +0800 Tag PDS 0.98f commit 7abe04420b766ded96c050989173bdeae420e99a Author: Alfred Chen Date: Thu Nov 16 21:37:57 2017 +0800 pds: Fix set task to offline cpu warning. commit 2c3c4b16322841b4ae9eccb091ee86c54bffcd4c Author: Alfred Chen Date: Wed Nov 15 17:38:18 2017 +0800 pds: Fix task runtime accounting. commit e4e44895806dcface4315bf2144c19004214f0b5 Author: Alfred Chen Date: Tue Nov 14 15:12:50 2017 +0800 pds: Remove yield support. commit 3ccb299f955acbe3839e53ee25142c15b65539e2 Author: Alfred Chen Date: Mon Nov 13 10:11:07 2017 +0800 Tag PDS 0.98e commit 234f82de53e9e66717b929dbfd5d7d865855d9c3 Author: Alfred Chen Date: Mon Oct 23 16:48:03 2017 +0800 pds: [Sync] 5d68cc95fb24 sched/debug: Ignore TASK_IDLE for SysRq-W commit 9cd4cccf8b51a07a67d1a6d09db13af50c07b0ea Author: Alfred Chen Date: Mon Oct 23 16:39:27 2017 +0800 pds: [Sync] 4ff9083b8a9a sched/core: WARN() when migrating to an offline CPU commit 3000a7c288a2fd1a4d94babfb814a6689d6b155c Author: Alfred Chen Date: Mon Oct 23 15:59:38 2017 +0800 pds: [Sync] 74dc3384fc79 sched/debug: Use task_pid_nr_ns in /proc/$pid/sched commit ce49743d64a09c25421491166306bac95e6dffe5 Author: Alfred Chen Date: Mon Oct 23 15:36:13 2017 +0800 pds: [Sync] d89e588ca408 locking: Introduce smp_mb__after_spinlock() commit dfb60e2137347ba1ffc9870647a32e7d009f6b13 Author: Alfred Chen Date: Mon Oct 23 15:26:17 2017 +0800 pds: [Sync] 20435d84e5f2 sched/debug: Intruduce task_state_to_char() helper function commit 9759bd979e7f01e9e750bc2bda4686a3ad625552 Author: Alfred Chen Date: Mon Oct 23 15:23:06 2017 +0800 pds: [Sync] 18f08dae1999 sched/core: Remove unnecessary initialization init_idle_bootup_task() commit f2a6cd8e07719109e3a0b7bb561a7fb946091fdd Author: Alfred Chen Date: Mon Oct 23 15:19:52 2017 +0800 pds: [Sync] 23a9b748a3d2 sched: Replace spin_unlock_wait() with lock/unlock pair commit 44a3bb72956a937dad6179c1a2975bc5d94d2e07 Author: Alfred Chen Date: Mon Oct 23 15:16:23 2017 +0800 pds: [Sync] 22e4ebb97582 membarrier: Provide expedited private command commit 9bd55e0e335ec42acee47d2015bd383519e23ec0 Author: Alfred Chen Date: Mon Oct 23 15:11:19 2017 +0800 pds: [Sync] 966a967116e6 smp: Avoid using two cache lines for struct call_single_data commit 6b9ffcfade6dbd689e8b84c00a0fcbe9741d0c2c Author: Alfred Chen Date: Mon Oct 23 15:08:04 2017 +0800 pds: [Sync] 955dbdf4ce87 sched: Allow migrating kthreads into online but inactive CPUs commit 4c9bc678196903639e59a0adf81dc09e51c6dccc Author: Alfred Chen Date: Mon Nov 13 14:03:39 2017 +0800 PDS-mq 0.98d Priority and Deadline based Skiplist multiple queue Scheduler Detail document at Documentation/scheduler/sched-PDS-mq.txt Project git repository at https://github.com/cchalpha/linux-gc *Updated for Kernel 4.16 -Alfred Chen commit 81a7144c4030e0bc4bdea97e3845b8839a4be6af Author: Alfred Chen Date: Thu Jul 2 14:22:39 2015 +0800 Keyboard backlight for ChromeOS and Pixel. commit f8ddaa3e0510c31c5c3477c4fdfa00a4ddf1f7a7 Author: Alfred Chen Date: Wed Jul 1 13:53:23 2015 +0800 atkbd: Remapping PS/2 keyboard for ChromebookPixel This establishes a somewhat generic way to do this and implements a specific solution for the Pixel where the right Ctrl key is redefined to be an Fn key. Press/release events for the fake Fn key are no longer reported up, but if the fake Fn key is pressed, then other keys are potentially translated. Implemented in this patch are the following mappings: Search Key(Win) -> CapsLock Right Alt -> Win Right Ctrl -> Fn with Fn held BS -> Delete Up -> PgUp Down -> PgDn Left -> Home Right -> End F6 -> Brightness Down(need setkeys 224 in userland) F7 -> Brightness Up(need setkeys 225 in userland) F8 -> Volume Mute F9 -> Volume Down F10 -> Volume Up Original writen by Dirk Hohndel Updated by Alfred Chen commit 6a85f1745a99052d3541f43265f5cf73bbee0034 Author: Alfred Chen Date: Wed Dec 4 13:55:22 2013 +0800 Use prefered raid6 gen function. commit d74fbb955ad6501405b1ec3d8ab052ff591213ce Author: Alfred Chen Date: Sat Oct 26 07:31:05 2013 +0800 Add XOR_PREFER_TEMPLATE to xor[v2]. Use XOR_PREFER_TEMPLATE can avoid xor template checking at bootup. commit 29dcea88779c856c7dc92040a0c01233263101d4 Author: Linus Torvalds Date: Sun Jun 3 14:15:21 2018 -0700 Linux 4.17 commit 325e14f97e0c92735d10d9922cbb73ad521de4c4 Merge: 874cd339acdf af04fadcaa93 Author: Linus Torvalds Date: Sun Jun 3 11:01:28 2018 -0700 Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs fixes from Al Viro. - fix io_destroy()/aio_complete() race - the vfs_open() change to get rid of open_check_o_direct() boilerplate was nice, but buggy. Al has a patch avoiding a revert, but that's definitely not a last-day fodder, so for now revert it is... * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: Revert "fs: fold open_check_o_direct into do_dentry_open" fix io_destroy()/aio_complete() race commit af04fadcaa932d2d804699409d9d96dd5d85ce7f Author: Al Viro Date: Sat Jun 2 01:31:02 2018 -0400 Revert "fs: fold open_check_o_direct into do_dentry_open" This reverts commit cab64df194667dc5d9d786f0a895f647f5501c0d. Having vfs_open() in some cases drop the reference to struct file combined with error = vfs_open(path, f, cred); if (error) { put_filp(f); return ERR_PTR(error); } return f; is flat-out wrong. It used to be error = vfs_open(path, f, cred); if (!error) { /* from now on we need fput() to dispose of f */ error = open_check_o_direct(f); if (error) { fput(f); f = ERR_PTR(error); } } else { put_filp(f); f = ERR_PTR(error); } and sure, having that open_check_o_direct() boilerplate gotten rid of is nice, but not that way... Worse, another call chain (via finish_open()) is FUBAR now wrt FILE_OPENED handling - in that case we get error returned, with file already hit by fput() *AND* FILE_OPENED not set. Guess what happens in path_openat(), when it hits if (!(opened & FILE_OPENED)) { BUG_ON(!error); put_filp(file); } The root cause of all that crap is that the callers of do_dentry_open() have no way to tell which way did it fail; while that could be fixed up (by passing something like int *opened to do_dentry_open() and have it marked if we'd called ->open()), it's probably much too late in the cycle to do so right now. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds commit 874cd339acdfe734b5418e36e3ad40fd4c573155 Merge: 26bdace74c85 595058b6675e Author: Linus Torvalds Date: Sun Jun 3 09:01:41 2018 -0700 Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Thomas Gleixner: - two patches addressing the problem that the scheduler allows under certain conditions user space tasks to be scheduled on CPUs which are not yet fully booted which causes a few subtle and hard to debug issue - add a missing runqueue clock update in the deadline scheduler which triggers a warning under certain circumstances - fix a silly typo in the scheduler header file * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/headers: Fix typo sched/deadline: Fix missing clock update sched/core: Require cpu_active() in select_task_rq(), for user tasks sched/core: Fix rules for running on online && !active CPUs commit 26bdace74c857ce370ca23344e79b0b7cc17e9b3 Merge: 918fe1b31579 6497bbc35ac5 Author: Linus Torvalds Date: Sun Jun 3 08:58:59 2018 -0700 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf tooling fixes from Thomas Gleixner: - fix 'perf test Session topology' segfault on s390 (Thomas Richter) - fix NULL return handling in bpf__prepare_load() (YueHaibing) - fix indexing on Coresight ETM packet queue decoder (Mathieu Poirier) - fix perf.data format description of NRCPUS header (Arnaldo Carvalho de Melo) - update perf.data documentation section on cpu topology - handle uncore event aliases in small groups properly (Kan Liang) - add missing perf_sample.addr into python sample dictionary (Leo Yan) * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf tools: Fix perf.data format description of NRCPUS header perf script python: Add addr into perf sample dict perf data: Update documentation section on cpu topology perf cs-etm: Fix indexing for decoder packet queue perf bpf: Fix NULL return handling in bpf__prepare_load() perf test: "Session topology" dumps core on s390 perf parse-events: Handle uncore event aliases in small groups properly