Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1702799 > unrolled thread
| Started by | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| First post | 2017-08-03 11:00 +0200 |
| Last post | 2017-08-08 19:20 +0200 |
| Articles | 9 on this page of 29 — 3 participants |
Back to article view | Back to linux.kernel
Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-03 11:00 +0200
Re: Switching to MQ by default may generate some bug reports Ming Lei <tom.leiming@gmail.com> - 2017-08-03 11:20 +0200
Re: Switching to MQ by default may generate some bug reports Ming Lei <tom.leiming@gmail.com> - 2017-08-03 11:40 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-03 11:50 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-03 11:50 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-03 12:50 +0200
Re: Switching to MQ by default may generate some bug reports Ming Lei <tom.leiming@gmail.com> - 2017-08-03 12:10 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-03 12:50 +0200
Re: Switching to MQ by default may generate some bug reports Ming Lei <tom.leiming@gmail.com> - 2017-08-03 13:50 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-03 11:30 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-03 13:10 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-04 09:30 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-04 13:10 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-05 00:10 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-05 14:00 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-07 19:40 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-07 19:40 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-07 20:50 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-08 10:10 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-08 19:40 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-08 20:30 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-09 23:50 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-10 10:50 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-08 12:40 +0200
Re: Switching to MQ by default may generate some bug reports Ming Lei <tom.leiming@gmail.com> - 2017-08-08 12:50 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-08 13:30 +0200
Re: Switching to MQ by default may generate some bug reports Ming Lei <tom.leiming@gmail.com> - 2017-08-08 14:00 +0200
Re: Switching to MQ by default may generate some bug reports Mel Gorman <mgorman@techsingularity.net> - 2017-08-08 14:00 +0200
Re: Switching to MQ by default may generate some bug reports Paolo Valente <paolo.valente@linaro.org> - 2017-08-08 19:20 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Date | 2017-08-08 20:30 +0200 |
| Message-ID | <uchqq-3H2-5@gated-at.bofh.it> |
| In reply to | #1706778 |
On Tue, Aug 08, 2017 at 07:33:37PM +0200, Paolo Valente wrote: > > Differently from bfq-sq, setting slice_idle to 0 doesn't provide any > > benefit, which lets me suspect that there is some other issue in > > blk-mq (only a suspect). I think I may have already understood how to > > guarantee that bfq almost never idles the device uselessly also for > > this workload. Yet, since in blk-mq there is no gain even after > > excluding useless idling, I'll wait for at least Ming's patches to be > > merged before possibly proposing this contribution. Maybe some other > > little issue related to this lack of gain in blk-mq will be found and > > solved in the meantime. > > > > Moving to the read-write unfairness problem. > > > > I've reproduced the unfairness issue (rand reader throttled by heavy > writers) with bfq, using > configs/config-global-dhp__io-fio-randread-sync-heavywrite, but with > an important side problem: cfq suffers from exactly the same > unfairness (785kB/s writers, 13.4kB/s reader). Of course, this > happens in my system, with a HITACHI HTS727550A9E364. > It's interesting that CFQ suffers the same on your system. It's possible that this is down to luck and the results depend not only on the disk but the number of CPUs. At absolute minimum we saw different latency figures from dbench even if the only observation s "different machines behave differently, news at 11". If the results are inconsistent, then the value of the benchmark can be dropped as a basis of comparison between IO schedulers (although I'll be keeping it for detecting regressions between releases). When the v4 results from Ming's patches complete, I'll double check the results from this config. > This discrepancy with your results makes a little bit harder for me to > understand how to better proceed, as I see no regression. Anyway, > since this reader-throttling issue seems relevant, I have investigated > it a little more in depth. The cause of the throttling is that the > fdatasync frequently performed by the writers in this test turns the > I/O of the writers into a 100% sync I/O. And neither bfq or cfq > differentiate bandwidth between sync reads and sync writes. Basically > both cfq and bfq are willing to dispatch the I/O requests of each > writer for a time slot equal to that devoted to the reader. But write > requests, after reaching the device, use the latter for much more time > than reads. This delays the completion of the requests of the reader, > and, being the I/O sync, the issuing of the next I/O requests by the > reader. The final result is that the device spends most of the time > serving write requests, while the reader issues its read requests very > slowly. > That is certainly plausible and implies that the actual results depend too heavily on random timing factors and disk model to be really useful. > It might not be so difficult to balance this unfairness, although I'm > a little worried about changing bfq without being able to see the > regression you report. In case I give it a try, could I then count on > some testing on your machines? > Yes with the caveat that results take a variable amount of time depending on how many problems I'm juggling in the air and how many of them are occupying time on the machines. -- Mel Gorman SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Paolo Valente <paolo.valente@linaro.org> |
|---|---|
| Date | 2017-08-09 23:50 +0200 |
| Message-ID | <ucH1w-4uS-19@gated-at.bofh.it> |
| In reply to | #1706778 |
> Il giorno 08 ago 2017, alle ore 19:33, Paolo Valente <paolo.valente@linaro.org> ha scritto: > >> >> Il giorno 08 ago 2017, alle ore 10:06, Paolo Valente <paolo.valente@linaro.org> ha scritto: >> >>> >>> Il giorno 07 ago 2017, alle ore 20:42, Paolo Valente <paolo.valente@linaro.org> ha scritto: >>> >>>> >>>> Il giorno 07 ago 2017, alle ore 19:32, Paolo Valente <paolo.valente@linaro.org> ha scritto: >>>> >>>>> >>>>> Il giorno 05 ago 2017, alle ore 00:05, Paolo Valente <paolo.valente@linaro.org> ha scritto: >>>>> >>>>>> >>>>>> Il giorno 04 ago 2017, alle ore 13:01, Mel Gorman <mgorman@techsingularity.net> ha scritto: >>>>>> >>>>>> On Fri, Aug 04, 2017 at 09:26:20AM +0200, Paolo Valente wrote: >>>>>>>> I took that into account BFQ with low-latency was also tested and the >>>>>>>> impact was not a universal improvement although it can be a noticable >>>>>>>> improvement. From the same machine; >>>>>>>> >>>>>>>> dbench4 Loadfile Execution Time >>>>>>>> 4.12.0 4.12.0 4.12.0 >>>>>>>> legacy-cfq mq-bfq mq-bfq-tput >>>>>>>> Amean 1 80.67 ( 0.00%) 83.68 ( -3.74%) 84.70 ( -5.00%) >>>>>>>> Amean 2 92.87 ( 0.00%) 121.63 ( -30.96%) 88.74 ( 4.45%) >>>>>>>> Amean 4 102.72 ( 0.00%) 474.33 (-361.77%) 113.97 ( -10.95%) >>>>>>>> Amean 32 2543.93 ( 0.00%) 1927.65 ( 24.23%) 2038.74 ( 19.86%) >>>>>>>> >>>>>>> >>>>>>> Thanks for trying with low_latency disabled. If I read numbers >>>>>>> correctly, we move from a worst case of 361% higher execution time to >>>>>>> a worst case of 11%. With a best case of 20% of lower execution time. >>>>>>> >>>>>> >>>>>> Yes. >>>>>> >>>>>>> I asked you about none and mq-deadline in a previous email, because >>>>>>> actually we have a double change here: change of the I/O stack, and >>>>>>> change of the scheduler, with the first change probably not irrelevant >>>>>>> with respect to the second one. >>>>>>> >>>>>> >>>>>> True. However, the difference between legacy-deadline mq-deadline is >>>>>> roughly around the 5-10% mark across workloads for SSD. It's not >>>>>> universally true but the impact is not as severe. While this is not >>>>>> proof that the stack change is the sole root cause, it makes it less >>>>>> likely. >>>>>> >>>>> >>>>> I'm getting a little lost here. If I'm not mistaken, you are saying, >>>>> since the difference between two virtually identical schedulers >>>>> (legacy-deadline and mq-deadline) is only around 5-10%, while the >>>>> difference between cfq and mq-bfq-tput is higher, then in the latter >>>>> case it is not the stack's fault. Yet the loss of mq-bfq-tput in the >>>>> above test is exactly in the 5-10% range? What am I missing? Other >>>>> tests with mq-bfq-tput not yet reported? >>>>> >>>>>>> By chance, according to what you have measured so far, is there any >>>>>>> test where, instead, you expect or have seen bfq-mq-tput to always >>>>>>> lose? I could start from there. >>>>>>> >>>>>> >>>>>> global-dhp__io-fio-randread-async-randwrite-xfs but marginal enough that >>>>>> it could be the stack change. >>>>>> >>>>>> global-dhp__io-dbench4-fsync-ext4 was a universal loss across any >>>>>> machine tested. This is global-dhp__io-dbench4-fsync from mmtests using >>>>>> ext4 as a filesystem. The same is not true for XFS so the filesystem >>>>>> matters. >>>>>> >>>>> >>>>> Ok, then I will try to repeat global-dhp__io-dbench4-fsync-ext4 as >>>>> soon as I can, thanks. >>>>> >>>>> >>>> >>>> I've run this test and tried to further investigate this regression. >>>> For the moment, the gist seems to be that blk-mq plays an important >>>> role, not only with bfq (unless I'm considering the wrong numbers). >>>> Even if your main purpose in this thread was just to give a heads-up, >>>> I guess it may be useful to share what I have found out. In addition, >>>> I want to ask for some help, to try to get closer to the possible >>>> causes of at least this regression. If you think it would be better >>>> to open a new thread on this stuff, I'll do it. >>>> >>>> First, I got mixed results on my system. I'll focus only on the the >>>> case where mq-bfq-tput achieves its worst relative performance w.r.t. >>>> to cfq, which happens with 64 clients. Still, also in this case >>>> mq-bfq is better than cfq in all average values, but Flush. I don't >>>> know which are the best/right values to look at, so, here's the final >>>> report for both schedulers: >>>> >>>> CFQ >>>> >>>> Operation Count AvgLat MaxLat >>>> -------------------------------------------------- >>>> Flush 13120 20.069 348.594 >>>> Close 133696 0.008 14.642 >>>> LockX 512 0.009 0.059 >>>> Rename 7552 1.857 415.418 >>>> ReadX 270720 0.141 535.632 >>>> WriteX 89591 421.961 6363.271 >>>> Unlink 34048 1.281 662.467 >>>> UnlockX 512 0.007 0.057 >>>> FIND_FIRST 62016 0.086 25.060 >>>> SET_FILE_INFORMATION 15616 0.995 176.621 >>>> QUERY_FILE_INFORMATION 28734 0.004 1.372 >>>> QUERY_PATH_INFORMATION 170240 0.163 820.292 >>>> QUERY_FS_INFORMATION 28736 0.017 4.110 >>>> NTCreateX 178688 0.437 905.567 >>>> >>>> MQ-BFQ-TPUT >>>> >>>> Operation Count AvgLat MaxLat >>>> -------------------------------------------------- >>>> Flush 13504 75.828 11196.035 >>>> Close 136896 0.004 3.855 >>>> LockX 640 0.005 0.031 >>>> Rename 8064 1.020 288.989 >>>> ReadX 297600 0.081 685.850 >>>> WriteX 93515 391.637 12681.517 >>>> Unlink 34880 0.500 146.928 >>>> UnlockX 640 0.004 0.032 >>>> FIND_FIRST 63680 0.045 222.491 >>>> SET_FILE_INFORMATION 16000 0.436 686.115 >>>> QUERY_FILE_INFORMATION 30464 0.003 0.773 >>>> QUERY_PATH_INFORMATION 175552 0.044 148.449 >>>> QUERY_FS_INFORMATION 29888 0.009 1.984 >>>> NTCreateX 183152 0.289 300.867 >>>> >>>> Are these results in line with yours for this test? >>>> >>>> Anyway, to investigate this regression more in depth, I took two >>>> further steps. First, I repeated the same test with bfq-sq, my >>>> out-of-tree version of bfq for legacy block (identical to mq-bfq apart >>>> from the changes needed for bfq to live in blk-mq). I got: >>>> >>>> BFQ-SQ-TPUT >>>> >>>> Operation Count AvgLat MaxLat >>>> -------------------------------------------------- >>>> Flush 12618 30.212 484.099 >>>> Close 123884 0.008 10.477 >>>> LockX 512 0.010 0.170 >>>> Rename 7296 2.032 426.409 >>>> ReadX 262179 0.251 985.478 >>>> WriteX 84072 461.398 7283.003 >>>> Unlink 33076 1.685 848.734 >>>> UnlockX 512 0.007 0.036 >>>> FIND_FIRST 58690 0.096 220.720 >>>> SET_FILE_INFORMATION 14976 1.792 466.435 >>>> QUERY_FILE_INFORMATION 26575 0.004 2.194 >>>> QUERY_PATH_INFORMATION 158125 0.112 614.063 >>>> QUERY_FS_INFORMATION 28224 0.017 1.385 >>>> NTCreateX 167877 0.827 945.644 >>>> >>>> So, the worst-case regression is now around 15%. This made me suspect >>>> that blk-mq influences results a lot for this test. To crosscheck, I >>>> compared legacy-deadline and mq-deadline too. >>>> >>> >>> Ok, found the problem for the 15% loss in bfq-sq. bfq-sq gets >>> occasionally confused by the workload, and grants device idling to >>> processes that, for this specific workload, would be better to >>> de-schedule immediately. If we set slice_idle to 0, then bfq-sq >>> becomes more or less equivalent to cfq (for some operations apparently >>> even much better): >>> >>> bfq-sq-tput-0idle >>> >>> Operation Count AvgLat MaxLat >>> -------------------------------------------------- >>> Flush 13013 17.888 280.517 >>> Close 133004 0.008 20.698 >>> LockX 512 0.008 0.088 >>> Rename 7427 2.041 193.232 >>> ReadX 270534 0.138 408.534 >>> WriteX 88598 429.615 6272.212 >>> Unlink 33734 1.205 559.152 >>> UnlockX 512 0.011 1.808 >>> FIND_FIRST 61762 0.087 23.012 >>> SET_FILE_INFORMATION 15337 1.322 220.155 >>> QUERY_FILE_INFORMATION 28415 0.004 0.559 >>> QUERY_PATH_INFORMATION 169423 0.150 580.570 >>> QUERY_FS_INFORMATION 28547 0.019 24.466 >>> NTCreateX 177618 0.544 681.795 >>> >>> I'll try soon with mq-bfq too, for which I expect however a deeper >>> investigation to be needed. >>> >> >> Hi, >> to test mq-bfq (with both slice_idle==0 and slice_idle>0), I have also >> applied Ming patches, and Ah, victory! >> >> Regardless of the value of slice idle: >> >> mq-bfq-tput >> >> Operation Count AvgLat MaxLat >> -------------------------------------------------- >> Flush 13183 70.381 1025.407 >> Close 134539 0.004 1.011 >> LockX 512 0.005 0.025 >> Rename 7721 0.740 404.979 >> ReadX 274422 0.126 873.364 >> WriteX 90535 408.371 7400.585 >> Unlink 34276 0.634 581.067 >> UnlockX 512 0.003 0.029 >> FIND_FIRST 62664 0.052 321.027 >> SET_FILE_INFORMATION 15981 0.234 124.739 >> QUERY_FILE_INFORMATION 29042 0.003 1.731 >> QUERY_PATH_INFORMATION 171769 0.032 522.415 >> QUERY_FS_INFORMATION 28958 0.009 3.043 >> NTCreateX 179643 0.298 687.466 >> >> Throughput 9.11183 MB/sec 64 clients 64 procs max_latency=7400.588 ms >> >> Differently from bfq-sq, setting slice_idle to 0 doesn't provide any >> benefit, which lets me suspect that there is some other issue in >> blk-mq (only a suspect). I think I may have already understood how to >> guarantee that bfq almost never idles the device uselessly also for >> this workload. Yet, since in blk-mq there is no gain even after >> excluding useless idling, I'll wait for at least Ming's patches to be >> merged before possibly proposing this contribution. Maybe some other >> little issue related to this lack of gain in blk-mq will be found and >> solved in the meantime. >> >> Moving to the read-write unfairness problem. >> > > I've reproduced the unfairness issue (rand reader throttled by heavy > writers) with bfq, using > configs/config-global-dhp__io-fio-randread-sync-heavywrite, but with > an important side problem: cfq suffers from exactly the same > unfairness (785kB/s writers, 13.4kB/s reader). Of course, this > happens in my system, with a HITACHI HTS727550A9E364. > > This discrepancy with your results makes a little bit harder for me to > understand how to better proceed, as I see no regression. Anyway, > since this reader-throttling issue seems relevant, I have investigated > it a little more in depth. The cause of the throttling is that the > fdatasync frequently performed by the writers in this test turns the > I/O of the writers into a 100% sync I/O. And neither bfq or cfq > differentiate bandwidth between sync reads and sync writes. Basically > both cfq and bfq are willing to dispatch the I/O requests of each > writer for a time slot equal to that devoted to the reader. But write > requests, after reaching the device, use the latter for much more time > than reads. This delays the completion of the requests of the reader, > and, being the I/O sync, the issuing of the next I/O requests by the > reader. The final result is that the device spends most of the time > serving write requests, while the reader issues its read requests very > slowly. > > It might not be so difficult to balance this unfairness, although I'm > a little worried about changing bfq without being able to see the > regression you report. In case I give it a try, could I then count on > some testing on your machines? > Hi Mel, I've investigated this test case a little bit more, and the outcome is unfortunately rather drastic, unless I'm missing some important point. It is impossible to control the rate of the reader with the exact configuration of this test. In fact, since iodepth is equal to 1, the reader issues one I/O request at a time. When one such request is dispatched, after some write requests have already been dispatched (and then queued in the device), the time to serve the request is controlled only by the device. The longer the device makes the read request wait before being served, the later the reader will see the completion of its request, and then the later the reader will issue a new request, and so on. So, for this test, it is mainly the device controller to decide the rate of the reader. On the other hand, the scheduler can gain again control of the bandwidth of the reader, if the reader issues more than one request at a time. Anyway, before analyzing this second, controllable case, I wanted to test responsiveness with this heavy write workload in the background. And it was very bad! After some hour of mild panic, I found out that this failure depends on a bug in bfq, bug that, luckily, happens to be triggered by these heavy writes as a background workload ... I've already found and am testing a fix for this bug. Yet, it will probably take me some week to submit this fix, because I'm finally going on vacation. Thanks, Paolo > Thanks, > Paolo > >> Thanks, >> Paolo >> >>> Thanks, >>> Paolo >>> >>>> LEGACY-DEADLINE >>>> >>>> Operation Count AvgLat MaxLat >>>> -------------------------------------------------- >>>> Flush 13267 9.622 298.206 >>>> Close 135692 0.007 10.627 >>>> LockX 640 0.008 0.066 >>>> Rename 7827 0.544 481.123 >>>> ReadX 285929 0.220 2698.442 >>>> WriteX 92309 430.867 5191.608 >>>> Unlink 34534 1.133 619.235 >>>> UnlockX 640 0.008 0.724 >>>> FIND_FIRST 63289 0.086 56.851 >>>> SET_FILE_INFORMATION 16000 1.254 844.065 >>>> QUERY_FILE_INFORMATION 29883 0.004 0.618 >>>> QUERY_PATH_INFORMATION 173232 0.089 1295.651 >>>> QUERY_FS_INFORMATION 29632 0.017 4.813 >>>> NTCreateX 181464 0.479 2214.343 >>>> >>>> >>>> MQ-DEADLINE >>>> >>>> Operation Count AvgLat MaxLat >>>> -------------------------------------------------- >>>> Flush 13760 90.542 13221.495 >>>> Close 137654 0.008 27.133 >>>> LockX 640 0.009 0.115 >>>> Rename 8064 1.062 246.759 >>>> ReadX 297956 0.051 347.018 >>>> WriteX 94698 425.636 15090.020 >>>> Unlink 35077 0.580 208.462 >>>> UnlockX 640 0.007 0.291 >>>> FIND_FIRST 66630 0.566 530.339 >>>> SET_FILE_INFORMATION 16000 1.419 811.494 >>>> QUERY_FILE_INFORMATION 30717 0.004 1.108 >>>> QUERY_PATH_INFORMATION 176153 0.182 517.419 >>>> QUERY_FS_INFORMATION 30857 0.018 18.562 >>>> NTCreateX 184145 0.281 582.076 >>>> >>>> So, with both bfq and deadline there seems to be a serious regression, >>>> especially on MaxLat, when moving from legacy block to blk-mq. The >>>> regression is much worse with deadline, as legacy-deadline has the >>>> lowest max latency among all the schedulers, whereas mq-deadline has >>>> the highest one. >>>> >>>> Regardless of the actual culprit of this regression, I would like to >>>> investigate further this issue. In this respect, I would like to ask >>>> for a little help. I would like to isolate the workloads generating >>>> the highest latencies. To this purpose, I had a look at the loadfile >>>> client-tiny.txt, and I still have a doubt: is every item in the >>>> loadfile executed somehow several times (for each value of the number >>>> of clients), or is it executed only once? More precisely, IIUC, for >>>> each operation reported in the above results, there are several items >>>> (lines) in the loadfile. So, is each of these items executed only >>>> once? >>>> >>>> I'm asking because, if it is executed only once, then I guess I can >>>> find the critical tasks ore easily. Finally, if it is actually >>>> executed only once, is it expected that the latency for such a task is >>>> one order of magnitude higher than that of the average latency for >>>> that group of tasks? I mean, is such a task intrinsically much >>>> heavier, and then expectedly much longer, or is the fact that latency >>>> is much higher for this task a sign that something in the kernel >>>> misbehaves for that task? >>>> >>>> While waiting for some feedback, I'm going to execute your test >>>> showing great unfairness between writes and reads, and to also check >>>> whether responsiveness does worsen if the write workload for that test >>>> is being executed in the background. >>>> >>>> Thanks, >>>> Paolo >>>> >>>>> ... >>>>>> -- >>>>>> Mel Gorman >>>>>> SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Date | 2017-08-10 10:50 +0200 |
| Message-ID | <ucRkf-2YH-21@gated-at.bofh.it> |
| In reply to | #1707984 |
On Wed, Aug 09, 2017 at 11:49:17PM +0200, Paolo Valente wrote: > > This discrepancy with your results makes a little bit harder for me to > > understand how to better proceed, as I see no regression. Anyway, > > since this reader-throttling issue seems relevant, I have investigated > > it a little more in depth. The cause of the throttling is that the > > fdatasync frequently performed by the writers in this test turns the > > I/O of the writers into a 100% sync I/O. And neither bfq or cfq > > differentiate bandwidth between sync reads and sync writes. Basically > > both cfq and bfq are willing to dispatch the I/O requests of each > > writer for a time slot equal to that devoted to the reader. But write > > requests, after reaching the device, use the latter for much more time > > than reads. This delays the completion of the requests of the reader, > > and, being the I/O sync, the issuing of the next I/O requests by the > > reader. The final result is that the device spends most of the time > > serving write requests, while the reader issues its read requests very > > slowly. > > > > It might not be so difficult to balance this unfairness, although I'm > > a little worried about changing bfq without being able to see the > > regression you report. In case I give it a try, could I then count on > > some testing on your machines? > > > > Hi Mel, > I've investigated this test case a little bit more, and the outcome is > unfortunately rather drastic, unless I'm missing some important point. > It is impossible to control the rate of the reader with the exact > configuration of this test. Correct, both are simply competing for access to IO. Very broadly speaking, it's only checking for loose (but not perfect) fairness with different IO patterns. While it's not a recent problem, historically (2+ years ago) we had problems whereby a heavy reader or writer could starve IO completely. It had odd effects like some multi-threaded benchmarks being artifically good simply because one thread would dominate and artifically complete faster and exit prematurely. "Fixing" it had a tendency to help real workloads while hurting some benchmarks so it's not straight-forward to control for properly. Bottom line, I'm not necessarily worried if a particular benchmark shows an apparent regression once I understand why and can convince myself that a "real" workload benefits from it (preferably proving it). > In fact, since iodepth is equal to 1, the > reader issues one I/O request at a time. When one such request is > dispatched, after some write requests have already been dispatched > (and then queued in the device), the time to serve the request is > controlled only by the device. The longer the device makes the read > request wait before being served, the later the reader will see the > completion of its request, and then the later the reader will issue a > new request, and so on. So, for this test, it is mainly the device > controller to decide the rate of the reader. > Understood. It's less than ideal but not a completely silly test either. That said, the fio tests are relatively new compared to some of the tests monitored by mmtests looking for issues. It can take time to finalise a test configuration before it's giving useful data 100% of the time. > On the other hand, the scheduler can gain again control of the > bandwidth of the reader, if the reader issues more than one request at > a time. Ok, I'll take it as a todo item to increase the depth as a depth of 1 is not that interesting as such. It's also on my todo list to add fio configs that add think time. > Anyway, before analyzing this second, controllable case, I > wanted to test responsiveness with this heavy write workload in the > background. And it was very bad! After some hour of mild panic, I > found out that this failure depends on a bug in bfq, bug that, > luckily, happens to be triggered by these heavy writes as a background > workload ... > > I've already found and am testing a fix for this bug. Yet, it will > probably take me some week to submit this fix, because I'm finally > going on vacation. > This is obviously both good and bad. Bad in that the bug exists at all, good in that you detected it and a fix is possible. I don't think you have to panic considering that some of the pending fixes include Ming's work which won't be merged for quite some time and tests take a long time anyway. Whenever you get around to a fix after your vacation, just cc me and I'll queue it across a range of machines so you have some independent tests. A review from me would not be worth much as I haven't spent the time to fully understand BFQ yet. If the fixes do not hit until the next merge window or the window after that then someone who cares enough can do a performance-based -stable backport. If there are any bugs in the meantime (e.g. after 4.13 comes out) then there will be a series for the reporter to test. I think it's still reasonably positive that issues with MQ being enabled by default were detected within weeks with potential fixes in the pipeline. It's better than months passing before a distro picked up a suitable kernel and enough time passed for a coherent bug report to show up that's better than "my computer is slow". Thanks for the hard work and prompt research. -- Mel Gorman SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Date | 2017-08-08 12:40 +0200 |
| Message-ID | <uca5z-71u-9@gated-at.bofh.it> |
| In reply to | #1705738 |
On Mon, Aug 07, 2017 at 07:32:41PM +0200, Paolo Valente wrote: > >> global-dhp__io-dbench4-fsync-ext4 was a universal loss across any > >> machine tested. This is global-dhp__io-dbench4-fsync from mmtests using > >> ext4 as a filesystem. The same is not true for XFS so the filesystem > >> matters. > >> > > > > Ok, then I will try to repeat global-dhp__io-dbench4-fsync-ext4 as > > soon as I can, thanks. > > > > > > I've run this test and tried to further investigate this regression. > For the moment, the gist seems to be that blk-mq plays an important > role, not only with bfq (unless I'm considering the wrong numbers). > Even if your main purpose in this thread was just to give a heads-up, > I guess it may be useful to share what I have found out. In addition, > I want to ask for some help, to try to get closer to the possible > causes of at least this regression. If you think it would be better > to open a new thread on this stuff, I'll do it. > I don't think it's necessary unless Christoph or Jens object and I doubt they will. > First, I got mixed results on my system. For what it's worth, this is standard. In my experience, IO benchmarks are always multi-modal, particularly on rotary storage. Cases of universal win or universal loss for a scheduler or set of tuning are rare. > I'll focus only on the the > case where mq-bfq-tput achieves its worst relative performance w.r.t. > to cfq, which happens with 64 clients. Still, also in this case > mq-bfq is better than cfq in all average values, but Flush. I don't > know which are the best/right values to look at, so, here's the final > report for both schedulers: > For what it's worth, it has often been observed that dbench overall performance was dominated by flush costs. This is also true for the standard reported throughput figures rather than the modified load file elapsed time that mmtests reports. In dbench3 it was even worse where the "performance" was dominated by whether the temporary files were deleted before writeback started. > CFQ > > Operation Count AvgLat MaxLat > -------------------------------------------------- > Flush 13120 20.069 348.594 > Close 133696 0.008 14.642 > LockX 512 0.009 0.059 > Rename 7552 1.857 415.418 > ReadX 270720 0.141 535.632 > WriteX 89591 421.961 6363.271 > Unlink 34048 1.281 662.467 > UnlockX 512 0.007 0.057 > FIND_FIRST 62016 0.086 25.060 > SET_FILE_INFORMATION 15616 0.995 176.621 > QUERY_FILE_INFORMATION 28734 0.004 1.372 > QUERY_PATH_INFORMATION 170240 0.163 820.292 > QUERY_FS_INFORMATION 28736 0.017 4.110 > NTCreateX 178688 0.437 905.567 > > MQ-BFQ-TPUT > > Operation Count AvgLat MaxLat > -------------------------------------------------- > Flush 13504 75.828 11196.035 > Close 136896 0.004 3.855 > LockX 640 0.005 0.031 > Rename 8064 1.020 288.989 > ReadX 297600 0.081 685.850 > WriteX 93515 391.637 12681.517 > Unlink 34880 0.500 146.928 > UnlockX 640 0.004 0.032 > FIND_FIRST 63680 0.045 222.491 > SET_FILE_INFORMATION 16000 0.436 686.115 > QUERY_FILE_INFORMATION 30464 0.003 0.773 > QUERY_PATH_INFORMATION 175552 0.044 148.449 > QUERY_FS_INFORMATION 29888 0.009 1.984 > NTCreateX 183152 0.289 300.867 > > Are these results in line with yours for this test? > Very broadly speaking yes, but it varies. On a small machine, the differences in flush latency are visible but not as dramatic. It only has a few CPUs. On a machine that tops out with 32 CPUs, it is more noticable. On the one machine I have that topped out with CFQ/BFQ at 64 threads, the latency of flush is vaguely similar CFQ BFQ BFQ-TPUT latency avg-Flush-64 287.05 ( 0.00%) 389.14 ( -35.57%) 349.90 ( -21.90%) latency avg-Close-64 0.00 ( 0.00%) 0.00 ( -33.33%) 0.00 ( 0.00%) latency avg-LockX-64 0.01 ( 0.00%) 0.01 ( -16.67%) 0.01 ( 0.00%) latency avg-Rename-64 0.18 ( 0.00%) 0.21 ( -16.39%) 0.18 ( 3.28%) latency avg-ReadX-64 0.10 ( 0.00%) 0.15 ( -40.95%) 0.15 ( -40.95%) latency avg-WriteX-64 0.86 ( 0.00%) 0.81 ( 6.18%) 0.74 ( 13.75%) latency avg-Unlink-64 1.49 ( 0.00%) 1.52 ( -2.28%) 1.14 ( 23.69%) latency avg-UnlockX-64 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) latency avg-NTCreateX-64 0.26 ( 0.00%) 0.30 ( -16.15%) 0.21 ( 19.62%) So, different figures to yours but the general observation that flush latency is higher holds. > Anyway, to investigate this regression more in depth, I took two > further steps. First, I repeated the same test with bfq-sq, my > out-of-tree version of bfq for legacy block (identical to mq-bfq apart > from the changes needed for bfq to live in blk-mq). I got: > > <SNIP> > > So, with both bfq and deadline there seems to be a serious regression, > especially on MaxLat, when moving from legacy block to blk-mq. The > regression is much worse with deadline, as legacy-deadline has the > lowest max latency among all the schedulers, whereas mq-deadline has > the highest one. > I wouldn't worry too much about max latency simply because a large outliier can be due to multiple factors and it will be variable. However, I accept that deadline is not necessarily great either. > Regardless of the actual culprit of this regression, I would like to > investigate further this issue. In this respect, I would like to ask > for a little help. I would like to isolate the workloads generating > the highest latencies. To this purpose, I had a look at the loadfile > client-tiny.txt, and I still have a doubt: is every item in the > loadfile executed somehow several times (for each value of the number > of clients), or is it executed only once? More precisely, IIUC, for > each operation reported in the above results, there are several items > (lines) in the loadfile. So, is each of these items executed only > once? > The load file is executed multiple times. The normal loadfile was basically just the same commands, or very similar commands, run multiple times within a single load file. This made the workload too sensitive to the exact time the workload finished and too coarse. > I'm asking because, if it is executed only once, then I guess I can > find the critical tasks ore easily. Finally, if it is actually > executed only once, is it expected that the latency for such a task is > one order of magnitude higher than that of the average latency for > that group of tasks? I mean, is such a task intrinsically much > heavier, and then expectedly much longer, or is the fact that latency > is much higher for this task a sign that something in the kernel > misbehaves for that task? > I don't think it's quite as easily isolated. It's all the operations in combination that replicate the behaviour. If it was just a single operation like "fsync" then it would be fairly straight-forward but the full mix is relevant as it matters when writeback kicks off, when merges happen, how much dirty data was outstanding when writeback or sync started etc. I see you've made other responses to the thread so rather than respond individually o I've queued a subset of tests with Ming's v3 patchset as that was the latest branch at the time I looked. It'll take quite some time to execute as the grid I use to collect data is backlogged with other work o I've included pgioperf this time because it is good at demonstrate oddities related to fsync. Granted it's mostly simulating a database workload that is typically recommended to use deadline scheduler but I think it's still a useful demonstration o If you want a patch set queued that may improve workload pattern detection for dbench then I can add that to the grid with the caveat that results take time. It'll be a blind test as I'm not actively debugging IO-related problems right now. o I'll keep an eye out for other workloads that demonstrate empirically better performance given that a stopwatch and desktop performance is tough to quantify even though I'm typically working in other areas. While I don't spend a lot of time on IO-related problems, it would still be preferred if switching to MQ by default was a safe option so I'm interested enough to keep it in mind. -- Mel Gorman SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Ming Lei <tom.leiming@gmail.com> |
|---|---|
| Date | 2017-08-08 12:50 +0200 |
| Message-ID | <ucafg-767-19@gated-at.bofh.it> |
| In reply to | #1706304 |
Hi Mel Gorman,
On Tue, Aug 8, 2017 at 6:30 PM, Mel Gorman <mgorman@techsingularity.net> wrote:
....
>
> o I've queued a subset of tests with Ming's v3 patchset as that was the
> latest branch at the time I looked. It'll take quite some time to execute
> as the grid I use to collect data is backlogged with other work
The latest patchset is in the following post:
http://marc.info/?l=linux-block&m=150191624318513&w=2
And you can find it in my github:
https://github.com/ming1/linux/commits/blk-mq-dispatch_for_scsi.V4
--
Ming Lei
[toc] | [prev] | [next] | [standalone]
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Date | 2017-08-08 13:30 +0200 |
| Message-ID | <ucaRX-7FO-5@gated-at.bofh.it> |
| In reply to | #1706323 |
On Tue, Aug 08, 2017 at 06:43:03PM +0800, Ming Lei wrote: > Hi Mel Gorman, > > On Tue, Aug 8, 2017 at 6:30 PM, Mel Gorman <mgorman@techsingularity.net> wrote: > .... > > > > o I've queued a subset of tests with Ming's v3 patchset as that was the > > latest branch at the time I looked. It'll take quite some time to execute > > as the grid I use to collect data is backlogged with other work > > The latest patchset is in the following post: > > http://marc.info/?l=linux-block&m=150191624318513&w=2 > > And you can find it in my github: > > https://github.com/ming1/linux/commits/blk-mq-dispatch_for_scsi.V4 > Unfortunately, the tests were queued last Friday and are partially complete depending on when machines become available. As it is, v3 will take a few days to complete and a requeue would incur further delays. If you believe the results will be substantially different then I'll discard v3 and requeue. -- Mel Gorman SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Ming Lei <tom.leiming@gmail.com> |
|---|---|
| Date | 2017-08-08 14:00 +0200 |
| Message-ID | <ucbkZ-7TS-7@gated-at.bofh.it> |
| In reply to | #1706370 |
On Tue, Aug 8, 2017 at 7:27 PM, Mel Gorman <mgorman@techsingularity.net> wrote: > On Tue, Aug 08, 2017 at 06:43:03PM +0800, Ming Lei wrote: >> Hi Mel Gorman, >> >> On Tue, Aug 8, 2017 at 6:30 PM, Mel Gorman <mgorman@techsingularity.net> wrote: >> .... >> > >> > o I've queued a subset of tests with Ming's v3 patchset as that was the >> > latest branch at the time I looked. It'll take quite some time to execute >> > as the grid I use to collect data is backlogged with other work >> >> The latest patchset is in the following post: >> >> http://marc.info/?l=linux-block&m=150191624318513&w=2 >> >> And you can find it in my github: >> >> https://github.com/ming1/linux/commits/blk-mq-dispatch_for_scsi.V4 >> > > Unfortunately, the tests were queued last Friday and are partially complete > depending on when machines become available. As it is, v3 will take a few > days to complete and a requeue would incur further delays. If you believe > the results will be substantially different then I'll discard v3 and requeue. Firstly V3 on github(never posted out) causes boot hang if CPU cores is >= 16, so you need to check if the test is still running, :-( Also V3 on github may not perform well on IB SRP(or other low latency SCSI disk), so I improve bio merge in V4 and make IB SRP's perf better too, and it depends on devices. I suggest to focus on V2 posted in mail list(V4 in github). -- Ming Lei
[toc] | [prev] | [next] | [standalone]
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Date | 2017-08-08 14:00 +0200 |
| Message-ID | <ucbl1-7TS-43@gated-at.bofh.it> |
| In reply to | #1706417 |
On Tue, Aug 08, 2017 at 07:49:53PM +0800, Ming Lei wrote: > On Tue, Aug 8, 2017 at 7:27 PM, Mel Gorman <mgorman@techsingularity.net> wrote: > > On Tue, Aug 08, 2017 at 06:43:03PM +0800, Ming Lei wrote: > >> Hi Mel Gorman, > >> > >> On Tue, Aug 8, 2017 at 6:30 PM, Mel Gorman <mgorman@techsingularity.net> wrote: > >> .... > >> > > >> > o I've queued a subset of tests with Ming's v3 patchset as that was the > >> > latest branch at the time I looked. It'll take quite some time to execute > >> > as the grid I use to collect data is backlogged with other work > >> > >> The latest patchset is in the following post: > >> > >> http://marc.info/?l=linux-block&m=150191624318513&w=2 > >> > >> And you can find it in my github: > >> > >> https://github.com/ming1/linux/commits/blk-mq-dispatch_for_scsi.V4 > >> > > > > Unfortunately, the tests were queued last Friday and are partially complete > > depending on when machines become available. As it is, v3 will take a few > > days to complete and a requeue would incur further delays. If you believe > > the results will be substantially different then I'll discard v3 and requeue. > > Firstly V3 on github(never posted out) causes boot hang if CPU cores is >= 16, > so you need to check if the test is still running, :-( > By co-incidence, the few machines that have completed had core counts below this so I'll discard existing results and requeue. Thanks. -- Mel Gorman SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Paolo Valente <paolo.valente@linaro.org> |
|---|---|
| Date | 2017-08-08 19:20 +0200 |
| Message-ID | <ucgkF-34x-3@gated-at.bofh.it> |
| In reply to | #1706304 |
> Il giorno 08 ago 2017, alle ore 12:30, Mel Gorman <mgorman@techsingularity.net> ha scritto: > > On Mon, Aug 07, 2017 at 07:32:41PM +0200, Paolo Valente wrote: >>>> global-dhp__io-dbench4-fsync-ext4 was a universal loss across any >>>> machine tested. This is global-dhp__io-dbench4-fsync from mmtests using >>>> ext4 as a filesystem. The same is not true for XFS so the filesystem >>>> matters. >>>> >>> >>> Ok, then I will try to repeat global-dhp__io-dbench4-fsync-ext4 as >>> soon as I can, thanks. >>> >>> >> >> I've run this test and tried to further investigate this regression. >> For the moment, the gist seems to be that blk-mq plays an important >> role, not only with bfq (unless I'm considering the wrong numbers). >> Even if your main purpose in this thread was just to give a heads-up, >> I guess it may be useful to share what I have found out. In addition, >> I want to ask for some help, to try to get closer to the possible >> causes of at least this regression. If you think it would be better >> to open a new thread on this stuff, I'll do it. >> > > I don't think it's necessary unless Christoph or Jens object and I doubt > they will. > >> First, I got mixed results on my system. > > For what it's worth, this is standard. In my experience, IO benchmarks > are always multi-modal, particularly on rotary storage. Cases of universal > win or universal loss for a scheduler or set of tuning are rare. > >> I'll focus only on the the >> case where mq-bfq-tput achieves its worst relative performance w.r.t. >> to cfq, which happens with 64 clients. Still, also in this case >> mq-bfq is better than cfq in all average values, but Flush. I don't >> know which are the best/right values to look at, so, here's the final >> report for both schedulers: >> > > For what it's worth, it has often been observed that dbench overall > performance was dominated by flush costs. This is also true for the > standard reported throughput figures rather than the modified load file > elapsed time that mmtests reports. In dbench3 it was even worse where the > "performance" was dominated by whether the temporary files were deleted > before writeback started. > >> CFQ >> >> Operation Count AvgLat MaxLat >> -------------------------------------------------- >> Flush 13120 20.069 348.594 >> Close 133696 0.008 14.642 >> LockX 512 0.009 0.059 >> Rename 7552 1.857 415.418 >> ReadX 270720 0.141 535.632 >> WriteX 89591 421.961 6363.271 >> Unlink 34048 1.281 662.467 >> UnlockX 512 0.007 0.057 >> FIND_FIRST 62016 0.086 25.060 >> SET_FILE_INFORMATION 15616 0.995 176.621 >> QUERY_FILE_INFORMATION 28734 0.004 1.372 >> QUERY_PATH_INFORMATION 170240 0.163 820.292 >> QUERY_FS_INFORMATION 28736 0.017 4.110 >> NTCreateX 178688 0.437 905.567 >> >> MQ-BFQ-TPUT >> >> Operation Count AvgLat MaxLat >> -------------------------------------------------- >> Flush 13504 75.828 11196.035 >> Close 136896 0.004 3.855 >> LockX 640 0.005 0.031 >> Rename 8064 1.020 288.989 >> ReadX 297600 0.081 685.850 >> WriteX 93515 391.637 12681.517 >> Unlink 34880 0.500 146.928 >> UnlockX 640 0.004 0.032 >> FIND_FIRST 63680 0.045 222.491 >> SET_FILE_INFORMATION 16000 0.436 686.115 >> QUERY_FILE_INFORMATION 30464 0.003 0.773 >> QUERY_PATH_INFORMATION 175552 0.044 148.449 >> QUERY_FS_INFORMATION 29888 0.009 1.984 >> NTCreateX 183152 0.289 300.867 >> >> Are these results in line with yours for this test? >> > > Very broadly speaking yes, but it varies. On a small machine, the differences > in flush latency are visible but not as dramatic. It only has a few > CPUs. On a machine that tops out with 32 CPUs, it is more noticable. On > the one machine I have that topped out with CFQ/BFQ at 64 threads, the > latency of flush is vaguely similar > > CFQ BFQ BFQ-TPUT > latency avg-Flush-64 287.05 ( 0.00%) 389.14 ( -35.57%) 349.90 ( -21.90%) > latency avg-Close-64 0.00 ( 0.00%) 0.00 ( -33.33%) 0.00 ( 0.00%) > latency avg-LockX-64 0.01 ( 0.00%) 0.01 ( -16.67%) 0.01 ( 0.00%) > latency avg-Rename-64 0.18 ( 0.00%) 0.21 ( -16.39%) 0.18 ( 3.28%) > latency avg-ReadX-64 0.10 ( 0.00%) 0.15 ( -40.95%) 0.15 ( -40.95%) > latency avg-WriteX-64 0.86 ( 0.00%) 0.81 ( 6.18%) 0.74 ( 13.75%) > latency avg-Unlink-64 1.49 ( 0.00%) 1.52 ( -2.28%) 1.14 ( 23.69%) > latency avg-UnlockX-64 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) > latency avg-NTCreateX-64 0.26 ( 0.00%) 0.30 ( -16.15%) 0.21 ( 19.62%) > > So, different figures to yours but the general observation that flush > latency is higher holds. > >> Anyway, to investigate this regression more in depth, I took two >> further steps. First, I repeated the same test with bfq-sq, my >> out-of-tree version of bfq for legacy block (identical to mq-bfq apart >> from the changes needed for bfq to live in blk-mq). I got: >> >> <SNIP> >> >> So, with both bfq and deadline there seems to be a serious regression, >> especially on MaxLat, when moving from legacy block to blk-mq. The >> regression is much worse with deadline, as legacy-deadline has the >> lowest max latency among all the schedulers, whereas mq-deadline has >> the highest one. >> > > I wouldn't worry too much about max latency simply because a large > outliier can be due to multiple factors and it will be variable. > However, I accept that deadline is not necessarily great either. > >> Regardless of the actual culprit of this regression, I would like to >> investigate further this issue. In this respect, I would like to ask >> for a little help. I would like to isolate the workloads generating >> the highest latencies. To this purpose, I had a look at the loadfile >> client-tiny.txt, and I still have a doubt: is every item in the >> loadfile executed somehow several times (for each value of the number >> of clients), or is it executed only once? More precisely, IIUC, for >> each operation reported in the above results, there are several items >> (lines) in the loadfile. So, is each of these items executed only >> once? >> > > The load file is executed multiple times. The normal loadfile was > basically just the same commands, or very similar commands, run multiple > times within a single load file. This made the workload too sensitive to > the exact time the workload finished and too coarse. > >> I'm asking because, if it is executed only once, then I guess I can >> find the critical tasks ore easily. Finally, if it is actually >> executed only once, is it expected that the latency for such a task is >> one order of magnitude higher than that of the average latency for >> that group of tasks? I mean, is such a task intrinsically much >> heavier, and then expectedly much longer, or is the fact that latency >> is much higher for this task a sign that something in the kernel >> misbehaves for that task? >> > > I don't think it's quite as easily isolated. It's all the operations in > combination that replicate the behaviour. If it was just a single operation > like "fsync" then it would be fairly straight-forward but the full mix > is relevant as it matters when writeback kicks off, when merges happen, > how much dirty data was outstanding when writeback or sync started etc. > > I see you've made other responses to the thread so rather than respond > individually > > o I've queued a subset of tests with Ming's v3 patchset as that was the > latest branch at the time I looked. It'll take quite some time to execute > as the grid I use to collect data is backlogged with other work > > o I've included pgioperf this time because it is good at demonstrate > oddities related to fsync. Granted it's mostly simulating a database > workload that is typically recommended to use deadline scheduler but I > think it's still a useful demonstration > > o If you want a patch set queued that may improve workload pattern > detection for dbench then I can add that to the grid with the caveat that > results take time. It'll be a blind test as I'm not actively debugging > IO-related problems right now. > > o I'll keep an eye out for other workloads that demonstrate empirically > better performance given that a stopwatch and desktop performance is > tough to quantify even though I'm typically working in other areas. While > I don't spend a lot of time on IO-related problems, it would still > be preferred if switching to MQ by default was a safe option so I'm > interested enough to keep it in mind. > Hi Mel, thanks for your thorough responses (I'm about to write something about the read-write unfairness issue, with, again, some surprise). I want to reply only to your last point above. With our responsiveness benchmark of course you don't need a stopwatch, but, yes, to get some minimally comprehensive results you need a machine with at least a desktop application like a terminal installed. Thanks, Paolo > -- > Mel Gorman > SUSE Labs
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web