[ANNOUNCE] bfq for 2.6.33-34
Paolo Valente
I know you can't believe it, but here is bfq for 2.6.33 and 2.6.34!
Sorry for the overdue delivery; this is not, however, just a port to
2.6.3[34]. I made some changes to reduce latency and increase
throughput, and fixed a few bugs along the way. I hope that the
results I'm going to show you will soften your feelings toward my
slowness :)
I ran a good deal of tests, and I need to tell you several things to
sync with you on what I did/found, as well as on what I did not yet
do. The gist of the results is however that bfq seems to guarantee
definitely lower latencies than cfq; and to achieve a higher
aggregated throughput with most of the workloads considered, or the
same aggregated throughput with the other workloads. One night I also
heard one of the disks spin faster with bfq. Ok, kidding about that ...
If you already got bored with my chatter and just want to try bfq, all
the stuff related to bfq is here [1], or you can directly pick the
patchset here [2]. I did not resist trying to add bfq to zen, so
although you probably do not need it, you can also find a patch for
2.6.34-zen1 in [6].
For who wants to read further, I broke this long email into a sequence
of sections to avoid an endless stream of information.
HARDWARE AND GENERAL INFO ON THE TESTS
I ran several tests on the following three systems with both 2.6.33
and 2.6.34 (the reported peak rates have been measured with hdparm):
DISK CPU DISTRIBUTION
ATA MAXTOR 6L080L0 (82 GB, 55 MB/s) Athlon 64 3200+ Slackware 13.0
ATA MAXTOR 7L250S0 (250 GB, 61 MB/s) Pentium 4 3.2GHz Ubuntu 8.04
ATA MAXTOR STM332061 (320 GB, 89 MB/s) Athlon 64 3200+ Ubuntu 10.04
For short, I will call each of these systems just the slow, medium or
fast disk. Still to do: I did not yet run tests on RAIDs.
In all the tests the low_latency tunable of cfq was on. Each test was
repeated ten times, and the values shown in the sections below are
averages computed over these repetitions. The statistics I collected
are however much more detailed: min/max/avg/standard
deviation/confidence interval for several quantities (latency,
read/write/ total aggregated throughput, ...) have been computed
within each test and across multiple repetitions of each test. All
these numbers, for the fast disk, can be found in [3]. To see where
they come from, have a look at the README and at the programs
themselves in the collection of test scripts [4].
The results with 2.6.33 and 2.6.34 are essentially similar. However,
whereas bfq was quite stable, cfq got slightly better results with
2.6.34. So, for brevity I report here only the results with 2.6.34,
apart from where they differ significantly with respect to 2.6.33. In
that case also the results with 2.6.33 are reported.
COLD-CACHE STARTUP LATENCY OF SHORT COMMANDS
Executing short commands from a shell should be a common task for
which one may desire low latency on a desktop or server. To get an
idea of the latency guaranteed by bfq to these commands in presence of
peak disk workloads, I measured the time to launch some of them with
cold caches and while one of the following sets of readers/writers
were being executed in parallel: ten sequential readers (hereafter
called 10r-seq for short), ten random readers (10r-rand), five
sequential readers plus five sequential writers (5r5w-seq), five
random readers plus five random writers (5r5w-rand).
One of the commands tested was "bash -c exit". On the fast disk it was
executed in 0.32 seconds with 10r-seq or 0.41 secs with 10r-rand,
against 0.55 or 0.33 secs under cfq. This time boiled down to 0.20
secs with 5r5w-seq or 0.26 secs with 5r5w-rand, against 0.57 or 0.66
under cfq. Hence, apart from the 10r-rand case, where cfq provides a
0.08 secs lower latency, the latency with bfq is from almost 2 to
almost 3 times lower than with cfq. Consider that bfq achieves these
results without using any additional mechanism/policy to favour
latency-sensitive applications, as cfq instead does.
In each of the ten repetitions of the test, "bash -c exit" was
executed ten times, spaced by 1 second from each other. Under these
conditions, the disk aggregated throughput with bfq was 72.2 MB/s with
10r-seq and 73.2 MB/s with 5r5w-seq, against 59.9 MB/s and 56.6 with
cfq. With regard to random workloads, with bfq I got 0.74 MB/s with
10r-rand and 1.04 MB/s with 5r5w-rand, against 0.64 MB/s and 0.85 with
cfq. In the end with bfq the throughput was from about 15% to about
30% higher.
This lower latency/higher throughput result is probably due to the
more accurate scheduling policy of bfq, which allows it get a low
latency even if assigning high budgets to the readers. More in detail,
the maximum possible budget that could be assigned was equal to the
estimated maximum amount of sectors that could be transferred in 125 ms
(the default budget timeout) on the target disk. And we verified that
bfq did assign such high budgets.
On each of the other two disks bfq got similar relative performance
against cfq as on the fast disk. These latency results with short
commands should also confirm that bfq guarantees low latency to
periodic soft real-time applications, as we showed a while ago with
our experiments on video streaming (see the performance comparison in
[5]).
STARTUP LATENCY OF LONGER COMMANDS
What happens with longer commands? The main purpose of the scheduling
policy of bfq is fairness. As the size of the stuff that has to be
read to execute a command grows, fairness constraints become dominant
in determining how long it will take to complete the command on a
loaded disk. For example, if the disk is idle, it takes about 2
seconds to execute "konsole -e /bin/true" on the fast disk with cold
caches. And it takes around 19.9 secs with bfq if ten files are being
read at the same time, as fairness demands. This is still less than
the 26 secs measured with cfq, but it is definitely a long wait for a
user.
The appropriate, general solution would be at least assigning the
right weight to each application according to its requirements
(probably something more sophisticated is needed). Of course this
should be done somewhere above the block layer, which is definitely
out of the business of bfq :)
However, I tried to give the following low_latency tunable a try ...
EXPERIMENTAL LOW_LATENCY TUNABLE FOR BFQ, AND CAVEATS
When this tunable is on, the original weight of a just born queue is
multiplied by ten, then it is linearly decreased as the queue gets
service, until it becomes equal to the original weight. Especially,
with the current values of the parameters, the boosting is over, i.e.,
the original weight is reached, when the queue has got about 24MB
served. To prevent seeky processes from keeping a high weight for too
long, a queue has 6 seconds (real time) to consume these 24MB, after
which the boosting is unconditionally suspended. If an existing queue
becomes backlogged after being idle for 20 seconds or more, then it
enjoys this weight boosting again. Of course I got to these numbers
after some tuning or common sense (I hope :) ).
This mechanism is a source of unfairness against disk-bound long-lived
processes, which do not benefit from any weight boosting. Probably low
latency is almost always not worth this loss of fairness on a
server. In contrast, the user of a desktop may be willing to tolerate
a temporary drop of throughput of long-lived best-effort applications
(download, peer-to-peer exchange, ..) in return of a lower latency of
the task being started.
On the contrary, few users would be happy if their long-lived soft
real-time applications, as e.g. video or audio players, suffered from
increased latencies. To check this, I repeated several times the
following experiment with both bfq and cfq: 1) flushed caches, 2)
started playing a high-resolution film with mplayer, 3) started ten
sequential or random readers when the film reached a given point, 4)
measured the number of dropped frames after 10 seconds (shown on the
status line of the player). These are the results on the slow disk
(the one on which frame drops were of course higher). Apart from a few
unlucky runs for both schedulers, the results were more or less stable
around the following averages:
Number of dropped frames - slow disk - BFQ vs CFQ
Avg with 10 seq readers | Avg with 10 rand readers |
6 vs 10 | 5 vs 5 |
According to this test the boosting mechanism apparently causes no
harm with respect to what is guaranteed by cfq. This parity seems also
to suggest some caution in adding a similar mechanism to cfq.
One of the shortcomings of this test is the following. Since it was
better to give you numbers and not my impressions of how smoother the
video was played with bfq, I run this mplayer test on the three
systems remotely for practicality, with -ao null and -vo null. So, to
release bfq in this millennium, I did not yet perform also systematic
tests of loss of video/audio quality on real use cases (listening to
music, watching a movie, maybe an HD one). Iteratively launching
batches of file reads while playing back music is not my typical daily
activity :)
Now I can show you what happens after turning low_latency on in bfq.
COMMAND STARTUP LATENCY WITH LOW_LATENCY ON
Repeating the same test for "bash -c exit", the startup time falls to
at most 0.20 secs with any of the sequential workloads and at most
0.23 secs with any of the rand workloads. Hence it is always from
about 1.5 to about 3 times lower than cfq. Aggregated throughput
performance are substantially the same as with low_latency off.
Now the actual litmus test: "konsole -e /bin/true" :)
The results are summarized in the following table (it reports
latency/agg. throughput with bfq vs latency/agg. throughput with cfq):
konsole startup - fast disk - BFQ vs CFQ
Background workload | Latency [sec] | Agg. thr [MB/s]
---------------------------------------------------------
10r-seq | 2.88 vs 26.03 | 48 vs 58
5r5w-seq | 2.59 vs 14.18 | 71 vs 57
10r-rand | 2.87 vs 22.36 | 5.5 vs 1.5
5r5w-rand | 2.82 vs 13.03 | 5.8 vs 2.0
The latency drop is evident. The 9-times lower latency with 10r-seq is
however paid with a 20% loss of aggregated throughput, because with
this highly sequential workload the throughput fall is more pronounced
as the seeky pattern of konsole is favoured. In the other three cases
the aggregated throughput is always higher even if the latency is at
least 4.6 times lower.
I tested also "xterm /bin/true" and found that under bfq it is
executed in no more than 0.4 secs with any of the workloads, against
around 2.4 to 4.6 secs under cfq (depending on the
workload). Aggregated throughput performance is in the middle between
the results with konsole and with bash. On each of the other two disks
the relative performance of bfq against cfq was more or less the same
as on the fast disk, for any of the three commands.
KERNEL DEVELOPMENT TASKS (MAKE, CHECKOUT, MERGE)
I measured how much a kernel make, git checkout or git merge
progresses while one of the usual four workloads considered so far is
being served. About the 5r5w-seq and 5r5w-rand workloads, I verified
that they let these tasks almost starve with both schedulers. In fact,
a significant part of the work done by these tasks is writing files,
but writes are system-wide and end up in common flush queues. So a
per-queue disk scheduler has apparently no opportunity to save the
writes generated by these tasks from being overwhelmed by the ones of
relentless greedy writers. Thus I report here only the results with
the two workloads comprised of only readers.
Let us start with make. As I verified through tracing, each cc1
invoked by make generates really few read requests, usually served in
about 100 ms under bfq. Then it spends the (definitely longer) rest of
its life either using the CPU or waiting for its writes to be handed
over to the vm subsystem. In the end, most of the (little) control of
a disk scheduler over the progress of a task like this is related to
how the scheduler proportions writes with respect to reads. And bfq
does it more or less as cfq does on both the slow and the fast
disks. On the contrary, under 2.6.33 bfq throttles writes more than
cfq on the medium disk, and this has negative consequences, as shown
last. First, here are the results for make on the fast disk:
make - fast disk - BFQ vs CFQ
Background workload | Number of source files | Agg. thr [MB/s]
| compiled during the test |
------------------------------------------------------------------
10r-seq | 219 vs 197 | 74 vs 57
10r-rand | 261 vs 270 | 0.7 vs 0.7
As can be seen, whereas the number of files compiled is about the same
with any of the two schedulers, the aggregated throughput with bfq is
higher with 10r-seq.
Things differ in case of git merge and git checkout.
git merge / git checkout - fast disk - BFQ vs CFQ
Background workload | Progress of merge | Progress of checkout
| during the test | during the test
------------------------------------------------------------------
10r-seq | 19% vs 1.3% | 15.5% vs 2.5%
10r-rand | 25% vs 2.6% | 40.7% vs 16.1%
The reason for these better results may be that the two tasks are more
read-intensive than a make; but we did not investigate this issue
further. With both tasks the relative performance of the schedulers in
terms of aggregated throughput is close to the one with make.
The relative performance of bfq with respect to cfq on the other two
disks are similar to the one on the fast disk. As anticipated, the
performance is instead worse on the medium disk with 2.6.33. On this
system bfq reduces the write throughput by 26% to 50% with respect to
cfq in presence of sequential readers. Here are the consequences:
make / git merge / git checkout - medium disk 2.6.33 - BFQ vs CFQ
Backgr. workload | Num. files compiled | Progr. of merge | Progr. of
checkout
| during make test | during the test | during the test
-----------------------------------------------------------------------------
10r-seq | 55 vs 134 | 5% vs 4.9% | 3.2% vs 3%
10r-rand | 286 vs 131 | 13.9% vs 5.8% | 17.2% vs 12.41%
The improvement of bfq drops with merge and checkout, and the
performance is even worse than cfq for make with sequential readers.
Yet bfq is definitely better than cfq for make with random
readers. These results with 2.6.33 should be further investigated.
AGGREGATED THROUGHPUT
As said several thousands lines ago, on one hand bfq quickly assigns
high budgets to non-seeky queues. On the other hand, the budget
timeout mechanism lets it naturally switch to a safe time slice scheme
for seeky queues, essentially the same as cfq. Here are the results of
these facts:
aggregated throughput - fast disk - BFQ vs CFQ
Workload | Agg. thr [MB/s]
---------------------------------------
10r-seq | 82.4 vs 66.1
5r5w-seq | 77.2 vs 62.4
10r-rand | 0.60 vs 0.60
5r5w-rand | 0.71 vs 0.83
Similar relative performance on the other two disks. I also
investigated a middle-ground scenario where two out of three
sequentially read files were interleaved on the disk surface (written
by running two dd in parallel). bfq achieved a higher throughput than
cfq also in this case. The analysis of these type of workloads has not
yet been deepened.
FAIRNESS
As you most certainly know, bfq works in the service, and not in the
time domain. This peculiar feature allows it to distribute the disk
throughput to non-seeky processes as desired (i.e., according to the
assigned weights). In particular, the desired throughput distribution
is guaranteed under any workload and independently of the disk
physical characteristics.
On the contrary, it is the disk time to be fairly distributed with
cfq. Due to ZBR, this results in unfairness in distributing the disk
throughput, in proportion to the distance between the files being
read/written. In [5] we already showed this fact with a varying number
of parallel reads. Repeating some of those tests on the fast disk, I
saw, for example, that two parallel readers of two 500MB distant files
run at 32.1 and 32.2 MB/s with bfq, against 34.1 and 30.7 MB/s with
cfq. In practice bfq equally redistributes the excess throughput given
by cfq to the process that reads the file in the faster zone of the
disk. In addition, under cfq the unlucky reader finishes later than
any of the two readers under bfq. Hence bfq also in this case enjoys a
higher average aggregated throughput.
As I saw from the traces, fairness and throughput are unsurprisingly
also related to when bfq treats a queue as seeky and when it does not.
And even sequential readers generate a seeky workload during part of
their life. Hence there may still be room for improvement, to increase
the throughput of each reader. In addition, further tuning might be
needed to get high throughput and/or fairness with workloads that I
did not yet consider. I did not yet look into these issues
further. Finally, thorough testing with differentiated weights is
still missing too.
WHAT IS CHANGED
As you probably understood, porting bfq to 2.6.3[34] was definitely a
negligible part of the work. In contrast, the main changes I made can
be summarized as follows (see the code for details):
1) re-tuned the budget feedback mechanism: it is now slightly more
biased toward assigning high budgets, to boost the aggregated
throughput more, and more quickly as new processes are started
2) introduced more tolerance toward seeky queues (I verified that the
phenomena described below used to occur systematically):
2a: if a queue is expired after having received very little
service, then it is not punished as a seeky queue, even if it
occurred to consume that little service too slowly; the
rationale is that, if the new active queue has been served for
a too short time interval, then its possible sequential
accesses may not yet prevail on the initial latencies for
moving the disk head on the first sector requested
2b: the waiting time (disk idling) of a queue detected as seeky as
a function of the position of the requests it issued is reduced
to a very low value only after the queue has consumed a minimum
fraction of the assigned budget; this prevents processes
generating (partly) seeky workloads from being too ill-treated
2c: if a queue has consumed 'enough' budget upon a budget timeout,
then, even if it did not consume all of its budget, that queue is
not punished as any seeky queue; the rationale is that, depending
on the disk zones, a queue may be served at a lower rate than the
estimated peak rate.
Changes 2a and 2b have been critical in lowering latencies, whereas
change 2c, in addition to change 1, helped a lot increase the disk
throughput.
3) slightly changed the peak rate estimator: a low-pass filter is now
used instead of just keeping the highest rate sampled; the rationale
is that the peak rate of a disk should be quite stable, so the filter
should converge more or less smoothly to the right value; it seemed to
correctly catch the peak rate with all the three disks
4) added the low latency mechanism already described in detail in the
previous sections
WHAT IS MISSING
I did not yet implement any of the cool features introduced in cfq
after the first release of bfq: fail-safe queue allocation, simplified
dispatch cycle, SSD tweaks and so on ... Besides, bfq-cgroup should
probably be integrated within blk-cgroup to implement a common
interface. Finally, the many constants used might be further tuned.
Any help for these upgrades is very welcome. Or else, if you prefer me
to retire this version of bfq until I also add that stuff, just tell
me ... Guess how soon you will get it back, given my very high time
budget :)
ACKNOWLEDGMENTS
I wish to thank Francesco Allertsen for porting the previous version of
bfq to 2.6.33 and for running several preliminary tests. I thank also
Mauro Andreolini for its technical help, which spared me several
debugging nightmares.
Thanks for surviving to this email.
Enjoy your disks,
Paolo
[1] http://algo.ing.unimo.it/people/paolo/disk_sched/
[2] http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php
[3] http://algo.ing.unimo.it/people/paolo/disk_sched/fast_disk-results.tgz
[4] http://algo.ing.unimo.it/people/paolo/disk_sched/test-suite.tgz
[5] http://algo.ing.unimo.it/people/paolo/disk_sched/comparison.php
[6] http://algo.ing.unimo.it/people/paolo/disk_sched/patches/2.6.34-zen1
Steven Barrett
> Hi,
> I know you can't believe it, but here is bfq for 2.6.33 and 2.6.34!
> Sorry for the overdue delivery; this is not, however, just a port to
> 2.6.3[34]. I made some changes to reduce latency and increase
> throughput, and fixed a few bugs along the way. I hope that the
> results I'm going to show you will soften your feelings toward my
> slowness :)
>
> I ran a good deal of tests, and I need to tell you several things to
> sync with you on what I did/found, as well as on what I did not yet
> do. The gist of the results is however that bfq seems to guarantee
> definitely lower latencies than cfq; and to achieve a higher
> aggregated throughput with most of the workloads considered, or the
> same aggregated throughput with the other workloads. One night I also
> heard one of the disks spin faster with bfq. Ok, kidding about that ...
>
> If you already got bored with my chatter and just want to try bfq, all
> the stuff related to bfq is here [1], or you can directly pick the
> patchset here [2]. I did not resist trying to add bfq to zen, so
> although you probably do not need it, you can also find a patch for
> 2.6.34-zen1 in [6].
>
I merged the patches to zen-stable, can't wait to test this!
Thanks Paolo!
l0tek
thanks paolo (and thanks to the zen team)
Paolo Valente
>
>
> I merged the patches to zen-stable, can't wait to test this!
>
>
Should you be using my test scripts, I just need to inform you that I
updated them (a little upgrade to make file size parametric also for
random readers/writers)
> Thanks Paolo!
Thank you for your interest :)
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.439 / Virus Database: 271.1.1/2985 - Release Date: 07/06/10 06:36:00
>
>
DAV
> omg! bfq and zen again on my pc!
> thanks paolo (and thanks to the zen team)
>
Yep guys! You are the best! :)
Manuel Knitza
Thanks! *compiling*
Alex Alexander
> Hi,
> I know you can't believe it, but here is bfq for 2.6.33 and 2.6.34!
> Sorry for the overdue delivery; this is not, however, just a port to
> 2.6.3[34]. I made some changes to reduce latency and increase
> throughput, and fixed a few bugs along the way. I hope that the
> results I'm going to show you will soften your feelings toward my
> slowness :)
>
> I ran a good deal of tests, and I need to tell you several things to
> sync with you on what I did/found, as well as on what I did not yet
> do. The gist of the results is however that bfq seems to guarantee
> definitely lower latencies than cfq; and to achieve a higher
> aggregated throughput with most of the workloads considered, or the
> same aggregated throughput with the other workloads. One night I also
> heard one of the disks spin faster with bfq. Ok, kidding about that ...
>
> If you already got bored with my chatter and just want to try bfq, all
> the stuff related to bfq is here [1], or you can directly pick the
> patchset here [2]. I did not resist trying to add bfq to zen, so
> although you probably do not need it, you can also find a patch for
> 2.6.34-zen1 in [6].
Many thanks :)
I've added the patches in Gentoo's zen-sources-2.6.34_p1 ebuild, they
can be applied by activating the "bfq" USE flag.
Cheers,
--
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com
Markos Chandras
Those patches doesn't seem to work for me
CC block/noop-iosched.o
CC block/deadline-iosched.o
CC block/cfq-iosched.o
CC block/sio-iosched.o
make[1]: *** No rule to make target `block/bfq-iosched.o',
needed by `block/built-in.o'. Stop.
make: *** [block] Error 2
Mystical linux # grep BFQ .config
CONFIG_IOSCHED_BFQ=y
CONFIG_DEFAULT_BFQ=y
Those are the BFQ related options on my .config
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Alex Alexander
It builds fine here, tested on two systems. Some missing config dependency perhaps?
> --
> Markos Chandras (hwoarang)
> Gentoo Linux Developer
> Web: http://hwoarang.silverarrow.org
--
Alex Alexander
>
> CC block/noop-iosched.o
> CC block/deadline-iosched.o
> CC block/cfq-iosched.o
> CC block/sio-iosched.o
> make[1]: *** No rule to make target `block/bfq-iosched.o',
> needed by `block/built-in.o'. Stop.
> make: *** [block] Error 2
>
> Mystical linux # grep BFQ .config
> CONFIG_IOSCHED_BFQ=y
> CONFIG_DEFAULT_BFQ=y
>
> Those are the BFQ related options on my .config
OK. I have no idea why it worked for me, but the 3rd patch didn't apply
properly.
epatch chose the wrong -p option. It was confused because the patch
contained only new files.
I've fixed it in zen-sources-2.6.34_p1-r1 :)
Steven Barrett
laptop fly - I can hardly tell that there is background load when I'm
opening apps and browsing with firefox, which is notorious for
freezing when it needs to read or write data.
Mladen Pejaković
> After a day and some, I can say with full confidence: BFQ makes my
> laptop fly - I can hardly tell that there is background load when I'm
> opening apps and browsing with firefox, which is notorious for
> freezing when it needs to read or write data.
>
Fantastic! :) Can't wait to get home and try it out!
Paolo Valente
Steven Barrett ha scritto:
> Version: 8.5.439 / Virus Database: 271.1.1/2987 - Release Date: 07/07/10 06:36:00
>
>
Angelo Di Stasi
Thank you Paolo!
Markos Chandras
> Hi,
> Thanks for surviving to this email.
> Enjoy your disks,
> Paolo
>
>
http://bugs.gentoo.org/show_bug.cgi?id=327415
According to the user, emerging zen-sources withough the bfq patches solves
the problem. CC your self there ( or any of the zen developers ) to request
further info from the user
Thanks
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
Francesco Allertsen
> Seems like the first bug related to this BFQ patch just poped up in
> Gentoo http://bugs.gentoo.org/show_bug.cgi?id=327415
Could you please ask him if he can try the vanilla kernel with bfq so we
can understand if it is a bfq related problem or a zen-kernel related.
Thanks
Bye
Francesco
Vit
Have you tried comparing BFQ vs NCQ with NOOP scheduler?
With best regards,
Victor.
--
Paolo Valente
> Thanks for your efforts.
It was a pleasure :)
> Have you tried comparing BFQ vs NCQ with NOOP scheduler?
disk, and compared the results against AS and CFQ, among others (but not
against NOOP). You can find the results in our paper on BFQ. We did not
repeat such tests because one of the interesting results (in my opinion
:) ) that we showed in that paper is that with NCQ no scheduler can
provide delay or fairness guarantees.
Ass a consequence, in presence of NCQ it would be very hard, if ever
possible, to provide for example low command startup latencies and/or
preserve reasonable request completion times for time-sensitive
long-lived processes. NCQ prevents BFQ from doing exactly what it has
been designed for.
So BFQ vs NCQ with NOOP is in a sense an apples to oranges comparison.
Yet I am curious about what would happen with respect to the aggregate
throughput; I will run some tests as soon as I persuade some of my
controllers to enable NCQ (or myself to buy a new controller :) ).
> With best regards,
> Victor.
>
>
> --
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
>
>
Mladen Pejaković
I have what appears to be the same or at least similar problem. System
wont start, but if I pass "elevator=cfq" to the kernel boot command it
starts normally. I'll post the logs, if I get them. :)
Mladen Pejaković
wrote:
> I have what appears to be the same or at least similar problem. System
> wont start, but if I pass "elevator=cfq" to the kernel boot command it
> starts normally. I'll post the logs, if I get them. :)
No logs, sorry. Disks aren't started at all. Here's what I had on my
monitor:
http://i25.tinypic.com/2ngbspu.jpg
Phlogi
Thanks
Steven Barrett
> Could anyone please merge linux-phc into zen-stable?
linux-phc is already merged into zen-stable.
On a side note, please don't hijack threads that are completely
irrelevant to your concerns; it's rude and literally off topic. Send
a new email with a different subject line so people can track and find
them next time.
Paolo Valente
this crash ...
A complete oops (e.g., through netconsole) might make my life easier;
but yours harder, as it might take some time to set up a net or serial
console :)
For the moment, could you send me your hw configuration,(dmesg, lshw or
whatever)?
Mladen Pejaković ha scritto:
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.441 / Virus Database: 271.1.1/3013 - Release Date: 07/18/10 06:35:00
>
>
Mladen Pejaković
the dmesg and lshw logs via ssh. :)
2010/7/21 Paolo Valente <posta...@yahoo.it>:
Paolo Valente
> I have what appears to be the same or at least similar problem. System
> wont start, but if I pass "elevator=cfq" to the kernel boot command it
> starts normally. I'll post the logs, if I get them. :)
linux (the distribution used by Mladen), and adding bfq, on a vm. Thanks
to the serial console he set up, we saw a strange behavior of a general
function, used (only once) in bfq. I already changed that line in a way
that should let things work. As soon as I am sure that the fix is
correct I will let you know the details and fix the patches.
Paolo Valente
I just removed the bug that caused the oops reported by Mladen, and
hopefully also the one on
http://bugs.gentoo.org/show_bug.cgi?id=327415
The cause of the oops was the following: as an additional check, bfq
controls whether the lock on the device queue has been taken when it is
asked to insert a new request. Before the fix, bfq did it through a
BUG_ON on the return value of the spin_is_locked function.
Unfortunately this function returns always false if CONFIG_SMP is not
set (as in the config files of the two guys reporting the oops). This
caused the BUG_ON to deceptively fire.
I replaced the BUG_ON with a call to assert_spin_locked, which should
work with any configuration.
I just fixed all the faulty patches. I hope this solved the problem.
Paolo
Paolo Valente
this is just to tell you that I published also an incremental patch to
apply the bug fix to the previous version of bfq. I gave some version
names and reorganized the patch archive a bit: the version of bfq before
the bugfix is now named v1, whereas the fixed one is v1-r1. You can find
the incremental patch to pass from v1 to v1-r1 here:
http://algo.ing.unimo.it/people/paolo/disk_sched/patches/previous_versions_revisions/incremental_patches/from_v1_to_v1-r1/0001-bfq_iosched-block-BUGFIX_in_spinlock_check-from_v1-to_v1-r1.patch
Paolo