[opensuse-kernel] Set SCSI_MQ_DEFAULT=n in Kernel:stable
Hi, currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support. We'll set the option to N in our stable kernels. The lack of scheduler support can cause significant performance drop. Vojtech reports 10-50x slowdown on random read workloads, the disks seek all over the platters due to the missing io scheduler optimizations. As most of our users are not likely to run on high-end storage devices or otherwise benefit from the scsi-mq feature, I believe it's safe to turn the scsi-mq option off. Once the io scheduler support is availabe we can enable it again. The change will be done for all architectures and all kernel flavors (30 changes in total). [1] http://www.spinics.net/lists/linux-scsi/msg75246.html -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 03/24/2015, 02:20 PM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
We'll set the option to N in our stable kernels.
Ok, but set the same on master too. The two kernels should be identical at every .0 release. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, Mar 24, 2015 at 03:21:16PM +0100, Jiri Slaby wrote:
We'll set the option to N in our stable kernels.
Ok, but set the same on master too. The two kernels should be identical at every .0 release.
Thanks for the reminder. Done. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/24/15 10:21 AM, Jiri Slaby wrote:
On 03/24/2015, 02:20 PM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
We'll set the option to N in our stable kernels.
Ok, but set the same on master too. The two kernels should be identical at every .0 release.
No, please don't. I'm in the middle of writing a longer reply to this because I think it's the wrong approach. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJVEXdNAAoJEB57S2MheeWyH2AP/0l9w45NMgZEyY2iiydYxNKF iq0Xc5lJ4CAujUPP3QSZhCCNj8Fo+p/5htYGeChNxdn7KByCCfXi6nq+oqxTLLQs Yl5pXs5LwqooV9ZL1TcA1v0p91qdgbcfBZ5Tt8uk9PzW5nVe83yCam0J1XywGVCl Q2qigWfm/2/Lxcxl+mHMmYq7VyBVFOMcjvRxeuNbT7vY895TGgOxTGpU9WV9MC+S m5a7gWV5GimdmTn/jr2Id45nz9wo032Uxq5hqHjFBaDRrFk5cY6F0V92sdvgBQCe kq9yR5pdNFDs8Kudsy7Zqp8efPmxyfwJZlMU12e6BXR3J2GMm4rFIXoH0rRrVzAc 4GtSc4+9ZeR2OArmSHRv6pLaBYtD8RtZcvrWlWyfo5rpEttyICPtJMj/w2k5h9jh JsrXasUcuMX4gqmVvYitpXVaoogBQjan/2fkDYL2O6F5ch2YHBuYOqFmOdZ+7pLE /j93YqK0qS8fwnA4c6IXfZWoo1UbMAxp2Ih9ommBTBEF8fpAmVr0h+YUBf1lS5Qq NqCMkNaCP7dPaZY2IbbcOlVZKws6HX3Fq85nQbu7DBLgB5Jq6Wbrs2u+8TAgGWeV SXVyrSk+dOxotSpvdpNbVE+dL4eXJKcnHJCoFsiRD8iOBBz4SpdN0p4GaWUgZHNK CGE9B2T61ZU6fQGPZpJK =kMcC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/24/2015 03:40 PM, Jeff Mahoney wrote:
On 3/24/15 10:21 AM, Jiri Slaby wrote:
On 03/24/2015, 02:20 PM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
We'll set the option to N in our stable kernels.
Ok, but set the same on master too. The two kernels should be identical at every .0 release.
No, please don't. I'm in the middle of writing a longer reply to this because I think it's the wrong approach.
Same here. If scsi-mq gives a degraded performance we should disable it on a per-driver basis, leaving the 'high-end' HBA free to profit from this. I'll gladly do a patch for this ... Cheers, Hannes - -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVEXf4AAoJEGz4yi9OyKjPHLgP/j3FEhGPSeFfJjpmzuqkkEj8 fqVl2GGeZkd7SzZci2Mxi4FLJU9/HUpJ+2vc7DA9ipI46d+Jlu1DX0gouDnfhQZJ UGWpJLfUm5tDYQZ+W1vXsZSBsHUkNlomSb0peN/K2yfLaesGEJ5oaGJVtCvKgchr BZG/rPICp9lDKih9rY0Of2RKhvAIoMQ1njkH8ePKwSQqBTv43gJ4f50IQ9nbZPBk D6oQu6IXklABPEkZEyRCt1pSBrHGapVcBnu6iquUYAcrcFpVi5+yBdJzw3cwp6ef lG964X/vSfGIs+Jkm17uNss4KJu5Vwur1kDirmO6qLWJBH4cgt4fyP2RSUMrqbaZ 42YhjBL1b/riJ4NqMzrKBsSIYwy0KBkUWHRT5HFAcaV7xcO167eKtBwn8SI9z3sl PTP2VetHStSBhyjErYL8hEZqokWs8bVNAxd9xQrbZ5jLv7yOtJS/T2pBAAR0BBGS IQL0cv80lXKgPfLrJNpalbwI/fPxw6gR2hUGhLq/iVbUshVkSLOCk9+kGmuReL3i A/ggpPcg2NmvPrHjhIAH20lHcfWgSc8+YRKYPil7MgYA6lhB6o4+XwejLygOwoQP e2Rpi44PcNpOr9x+k/G7/f/sfUBnVeCjbPuDcc+cfec93VQoZLUaJZ6OxnmImBIZ Bw6NaEqZFC4cWs5KM37h =L90k -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/24/15 10:43 AM, Hannes Reinecke wrote:
On 03/24/2015 03:40 PM, Jeff Mahoney wrote:
On 3/24/15 10:21 AM, Jiri Slaby wrote:
On 03/24/2015, 02:20 PM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
We'll set the option to N in our stable kernels.
Ok, but set the same on master too. The two kernels should be identical at every .0 release.
No, please don't. I'm in the middle of writing a longer reply to this because I think it's the wrong approach.
Same here. If scsi-mq gives a degraded performance we should disable it on a per-driver basis, leaving the 'high-end' HBA free to profit from this.
I'll gladly do a patch for this ...
It doesn't even look like it would be that involved. There is already Scsi_Host->use_blk_mq. That's keyed off of scsi_mod.use_blk_mq and scsi_host_template->disable_blk_mq. The latter option obviously doesn't help much. It's more of an escape hatch if a particular HBA is well and truly hosed WRT mq. If we were to key Scsi_Host->use_blk_mq off of a more granular switch, that should help. But really what I'd like to see is granularity on a per-device basis or, perhaps more usefully, a way to shim classic block onto the end of blk-mq. blk-mq is lightweight enough and the target use cases are heavyweight enough that the overhead of passing through blk-mq might not matter. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJVEXvcAAoJEB57S2MheeWyXJQQAMB5Kzje+hGFL9pJOvZv2Ze/ uBVuSqKt9Kw8NPW+1tXXioKlrrsfhbWq4VmffC3LevefMsDRDa2DenhTMaBbA3te thKTDDip7gS9eibOAjgh46I1ZTu4hSmCWQSy7dYCVsymEg6pd82fGYH2LMUFuVVN zTEcIlAj31J1IgBa0+q8F7reavraHxR4cIq9ukeVbWDOniXw9BH+z/km3D7wh2wm poY0KG+zHVTe63G00ElGdYphdhuSDTaCAJwt3iif6Y5htclkQIT2lRyukdaya7NU sDfDwErJNnvlWHCouzEQ0tTdPljsy5Fcy20B737csiXwHrgo3w8POhC+LkNUZvcQ nXy1HGTMCsWuSd38wd/PgJhC3Jx/xFTws7MjXgY140pKMZiWd60ZvYH6xNX/flDr T/aGh+PSPaYJNNeho/xEfNrQ4jSbg4wDjr8iV2bKkYyuuV25nOYvzQ+0pu5oL+zq bxHauXMbwVwrdqx0y3W6KQLQsDS2veNhO4GAgXxB0ICNTOse118lVc4ry7PQLo98 qpmj8P+3ZZe3J4A33bF5LYTNFgWw+h5RqXlsv8fm5Xq6OdOuA1o0q9tVT4b5SyII S6LiztL+IKFuVD66VaMCPGFhDzR+kwFK3CFiMVG9WdERof7zCYM6zOaHXzRXiz2D Swa3oSqPu4fo8+jqdPjI =/ZtX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/24/2015, 03:40 PM, Jeff Mahoney wrote:
On 3/24/15 10:21 AM, Jiri Slaby wrote:
On 03/24/2015, 02:20 PM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
We'll set the option to N in our stable kernels.
Ok, but set the same on master too. The two kernels should be identical at every .0 release.
No, please don't. I'm in the middle of writing a longer reply to this because I think it's the wrong approach.
Ok, whatever is the result of this discussion, please make sure stable.configs == master.configs afterwards. thanks, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVEXhaAAoJEL0lsQQGtHBJit4QAKyfGPFeM5761CgkqY166ULd 0EcJRDn9uYrytghfBtSZpf9SNcNiZlVZzFyafhR7pl+pK6+Q+bejcc/gOqfar+eb Lq5MnJRng2P8+hYaUreSCubt+c8BGHHnPOaRPOwPPVtYeARer5ZgBPa+0xYtUI4t SCot7w7vP1EJa1h2LAVaz9XqEqV37PPfLgIqaJ8lZdw/5Wcxag289z/UtDwufmq2 Ya/YVBAAUjEwMHMZgjCT357LT0cm2OsO6odjzsnekhMk/OIft1Lkr45hBgBlnYYx tUShyYv+UK6YcrVyOl5TYWiovSaTC8AsZYZMTarK+6f1kHBNDNIiWXPO6EeIr3gB de1ITh3cpTJlu4+MM/nhFYFOrkDO5ORr4DhugUKXIFxIiIX1oTedZ85dQtr/IelK rFQIlO7dlRiZVNt+X5b1UItntYy56sN+o/JVwC1dkBdBx2kuzj3sVHXqo09b0APJ 0SzjsOKm5qt7ARUCr59TMQVIdJ63oNkXKDrLUTsHNEzmD9x8Q8DEg+aMDNjMCOL6 bo15wz2rkh3pDILfiv7CKBXuimiGQV9q/BAzvLUD5WHmQffI8ownITFh7N8Cu0fr pe9lnUA5Qa2VjlKKo9cLBcAk2/R9MeBCfQvy3PEKOoPktG8NwvPdUJwb/L6NNuJE SQgIGfOO1sFK77a8RESg =kuC+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/24/15 9:20 AM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
That's overstating the problem a bit. It lacks scheduler support because as we encounter devices capable of much higher numbers of IOPS with essentially zero seek latency, the time we spend processing requests starts to take longer than the I/O itself. This isn't limited to enterprise storage. I can order a commodity SSD this morning that meets this description for about the same price as a regular hard drive (obviously with less capacity.)
We'll set the option to N in our stable kernels.
The lack of scheduler support can cause significant performance drop. Vojtech reports 10-50x slowdown on random read workloads, the disks seek all over the platters due to the missing io scheduler optimizations.
As most of our users are not likely to run on high-end storage devices or otherwise benefit from the scsi-mq feature, I believe it's safe to turn the scsi-mq option off. Once the io scheduler support is availabe we can enable it again.
The change will be done for all architectures and all kernel flavors (30 changes in total).
I disagree. This is a scenario that benefits some hardware and costs other hardware, which is effectively the same scenario that exists without SCSI_MQ_DEFAULT. The difference is that the single queue block layer is dying and the multiqueue block layer is evolving. The config option is the default and it can be changed at runtime. We're talking about Factory. If users with Vojtech's configuration (which is pretty esoteric - it's more than just having a few spinning disks) need to back off scsi-mq, they can do it by booting with scsi_mod.use_blk_mq=0. There is basic infrastructure in place to choose old block or blk-mq on a per-host basis but it hasn't been fleshed out yet. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJVEXiGAAoJEB57S2MheeWy9FsP/Rq/Ng/DFSzCJxypd8k5yUVH Tpc2oeC1fOVtdw8B8oX51DS4MYjy3aAD3LEFRtuHRc1tlbk0moxGR73upvphPVlj 7Wg/KUBO0hOLkLSUvPP+4xCeanSapK++DELw2982QiF5QT5qK9kqCr1EmYhrim1x P9ruDovb+xZu/O00Qcw1P9pu1SqsOI4+KcEWeU6zIqX7P77oiJJF988eq0Xid5N9 APS6wJKftsmSgEYMdGMfAtd+pm5bQaZWGSYd7ASXnSUgYLaPz6sL5TbP1t2X5Zrb 1mObokCFr/JB9RErew3P8G7lyMRtum0gnjsk9j4Elx6vsn3EpH9N080tyEXuQXDL Z+9Xis0DW1tu6ISl/QiCzPnyfHMaBWHuuDw7JKqzVDCedt1RBG84o9XghhoPPwWf rcE10cxJrlPal1XqO+bGTAEKiuEmjaPpjfzX0fDwRROgyL87KRsUUTT8gcwab9Jf Bi1sa6Zbc8a0nwL8OaUFNd0qU96se25xjF/qzDlBI9PHrNScUdxQJLQ1Cuswjs0R VnK5NPpTFTwiCqvpzIf4lxtEBr7Ba+8NuIfJtjaSZ/nD0M8CPxByu6NrYwhlLhmz 6RPcqC2CjMxtSXzJXcAoomV1gMwJvp7bYd6Jd80NCQPkNJMgKSyplnII0rb7FZ5/ Xl1YUaEae6Ts42/UZQSo =ukOh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/24/2015, 03:45 PM, Jeff Mahoney wrote:
On 3/24/15 9:20 AM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
That's overstating the problem a bit. It lacks scheduler support because as we encounter devices capable of much higher numbers of IOPS with essentially zero seek latency, the time we spend processing requests starts to take longer than the I/O itself. This isn't limited to enterprise storage. I can order a commodity SSD this morning that meets this description for about the same price as a regular hard drive (obviously with less capacity.)
We'll set the option to N in our stable kernels.
The lack of scheduler support can cause significant performance drop. Vojtech reports 10-50x slowdown on random read workloads, the disks seek all over the platters due to the missing io scheduler optimizations.
As most of our users are not likely to run on high-end storage devices or otherwise benefit from the scsi-mq feature, I believe it's safe to turn the scsi-mq option off. Once the io scheduler support is availabe we can enable it again.
The change will be done for all architectures and all kernel flavors (30 changes in total).
I disagree. This is a scenario that benefits some hardware and costs other hardware, which is effectively the same scenario that exists without SCSI_MQ_DEFAULT. The difference is that the single queue block layer is dying and the multiqueue block layer is evolving.
The config option is the default and it can be changed at runtime. We're talking about Factory. If users with Vojtech's configuration (which is pretty esoteric - it's more than just having a few spinning disks) need to back off scsi-mq, they can do it by booting with scsi_mod.use_blk_mq=0. There is basic infrastructure in place to choose old block or blk-mq on a per-host basis but it hasn't been fleshed out yet.
David? It has been a week now and it remained disabled. So what is the result of this thread, please? thanks, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGqFnAAoJEL0lsQQGtHBJvyAP/0JRwnHoQMwVMbwS9DBwEAT5 gD3pM28Zii0UhUAcDAxtHdGEiYy++J4WBMRzgrDqDRgop1lYTC5sirZiv0NVP3+u Eoug9S1OpTSj3AR/EUnzVJy9MHOKnZoo3xxjIyXjp9rLH4tRKR+uVaHkCHFTZ88p Ohy+VGV3KbrG2ln2F67fdqTD38zYGI6iRrj91PZu7lApyP8KBDr6ZupUf8uvvKoB EEFfuSszt3QxkLuFlcnyXElZR+PwOUFPveYQD2cKfXNRSZrEolz5bwcFIerm8mvN CBBeh0ChHZ7YAATY9BRT3UygMUxsy9GfgKYe9wD3FLs4MXU3Aln+O3W3tjiMbuUP vdtAMlEWVAKOxia2QDvHLtJOTg0G9q3kODi7iCbyF1550ImPxmUIIRapUc8lkZly bnPRghmA74MA9rpcec+TA6twdJEybITr/aUjd2YBgsgGb69cgSGXgaJnF7QFSUrd AtRQjlnk/sq2Mqp1ZKFw+nU4s7T9gXCJON+FXk/YZGm+vjKpQutwB8en0CorE4qj bo6FfvXsAWvZdQ+kzAPm3iPEvUcJUljTXKZ7uGwL4GBS8MI9N28shsHsiVgsdw02 iuXbkJ8waViA1SnaMQPYwWhEdMPcLOASixds850vHK4RDxiDoZSDeR1DhTc+w3FN IoMbz897xiE6QUFMw5CY =r+be -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/31/2015, 03:30 PM, Jiri Slaby wrote:
On 03/24/2015, 03:45 PM, Jeff Mahoney wrote:
On 3/24/15 9:20 AM, David Sterba wrote:
Hi,
currently the scsi-mq is set to Y, since 3.18-rc1 merge. The option enables a feature that makes advantage of enterprise-class storage. It's known not to perform well on slower devices [1] and lacks scheduler support.
That's overstating the problem a bit. It lacks scheduler support because as we encounter devices capable of much higher numbers of IOPS with essentially zero seek latency, the time we spend processing requests starts to take longer than the I/O itself. This isn't limited to enterprise storage. I can order a commodity SSD this morning that meets this description for about the same price as a regular hard drive (obviously with less capacity.)
We'll set the option to N in our stable kernels.
The lack of scheduler support can cause significant performance drop. Vojtech reports 10-50x slowdown on random read workloads, the disks seek all over the platters due to the missing io scheduler optimizations.
As most of our users are not likely to run on high-end storage devices or otherwise benefit from the scsi-mq feature, I believe it's safe to turn the scsi-mq option off. Once the io scheduler support is availabe we can enable it again.
The change will be done for all architectures and all kernel flavors (30 changes in total).
I disagree. This is a scenario that benefits some hardware and costs other hardware, which is effectively the same scenario that exists without SCSI_MQ_DEFAULT. The difference is that the single queue block layer is dying and the multiqueue block layer is evolving.
The config option is the default and it can be changed at runtime. We're talking about Factory. If users with Vojtech's configuration (which is pretty esoteric - it's more than just having a few spinning disks) need to back off scsi-mq, they can do it by booting with scsi_mod.use_blk_mq=0. There is basic infrastructure in place to choose old block or blk-mq on a per-host basis but it hasn't been fleshed out yet.
David?
Ping: this is a month now. I will revert the change in master and merge to stable if there are no objections?
It has been a week now and it remained disabled. So what is the result of this thread, please?
thanks,
- -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVOJorAAoJEL0lsQQGtHBJ+ZsP/0pB115iSrKxSk12Lm6M1O+4 ybTdmHqhBcR4sd3RRhzL8+CcbV5E2v/OB6gn2K06YUYZW83dbsHeE8Rd53xlbtj5 NjsDbYBrMjBkDSVb3QgkyIPaOs6S6ToaVsz8ffV9EQuKNTbHyg72k3cOHpxxMX8N iyS9ozGivTPnS+G97Vj/J37/mUtC0Jv5vb7gUioo8A2/DhxxsTpWzaqiVSFgFAsP wvlMXgR0UeoWEQ3m65zNI3Jvh3zQ1m5zEI2uPCu8bp+WEgml37WgZs3vszKduUV/ bwy/LwqIKacMV2cXE0P3JAA9fM0ErQB9Y1n2kpVC+vnN+f0JfnaEufEpNBR16NH3 qr73MY47XB49oDIv1A6lBwps0N3CysmyMeZ5bNqwS6ciqpQuszPMNnGA4Mhl+3me pz8NWbUlknt8wnfuWRgPpNDgVg+qQLJkwIYeNRNBHgLjM3MmLfFX2Rkg/f8sa6Wf HcNqrKxFjk80plRLQzs/JZEz/3Qv7QMvIR2Gxloy2Pp7qvGAr+QqIWD5bmsig2a8 a8zsBdgvu7w4JVRnms+FgDICYsisSMh4/Xcu5v2f6/RCktgTzIjRXHNHNdZHKejB rH8tsm4SOgDRFWiL4eeCsA3AaNqE3mT4EDjNCBnFrG21WjHbhzpxkGl9fyKY8cl7 j/QHuzks4vgkSzP/XIg4 =229f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, Apr 23, 2015 at 09:07:28AM +0200, Jiri Slaby wrote:
per-host basis but it hasn't been fleshed out yet.
David?
Ping: this is a month now. I will revert the change in master and merge to stable if there are no objections?
Sorry, I forgot to reply. The summary was to keep the the default=n (ie. keep the patch). My understanding is that the drivers need to be enhanced to auto-tune to use single queue where appropriate. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/24/15 8:32 AM, David Sterba wrote:
On Thu, Apr 23, 2015 at 09:07:28AM +0200, Jiri Slaby wrote:
per-host basis but it hasn't been fleshed out yet.
David?
Ping: this is a month now. I will revert the change in master and merge to stable if there are no objections?
Sorry, I forgot to reply. The summary was to keep the the default=n (ie. keep the patch). My understanding is that the drivers need to be enhanced to auto-tune to use single queue where appropriate.
That was my understanding of the state of the change now too. Neither Hannes or I have had the time to do it yet. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJVOkreAAoJEB57S2MheeWyMioQAMHlbJ1JsqBVW39BAtkHbJyH ZkWm8WKW81t7D3cGCqcxeLf1R6wubI9KexzHpx2e142a8GoOqF3b0QIu81InyQA+ 0VgwX3I1S5qgQbtLv1lEAPk2EzodkUobxw5PuZlU+w7/nHJLucc0K4mjon/jeeLf hCjFVRXgiIn7NPg8GuuoCk2V9sOp5BJMEI9I9d4h9uBNf/PU63qX6TlMkvRZlyGV Q/ofyC9HGB6gOnm0L8Tzk86vFkD4KkhuPN21zF6LfGDbS2QzL6lej6ZXjcqDk/0n lFPSWjFqlqUmogVJEpTFzGyKKVpjQQQ0X2xrpi44Ud8aBSnCaRmhNdZmCd3zstg2 tVSN8gCmP6uQTITYlDbshSbz/N03KmTxIFnmsuZKgMACYoWB7cUEVD3FOuvOc72r xQsJLjFoKQCg5Z2DCfoQKeaWlFCyX8/xNpX644JIttCiVv6sATK/PnsCwL7j55fz RAES85cdwHNgWXNFhVMpO0R/LPUS6pE8RiLWPVIMkTl4BbTwNY6aaPm4dYS+DXrC sabPTntLpKWotEoz8qE4VXHQclhhrpo2t0MkH5XV0fUuGxurrxXIEZ2x+ZmnM21r IhWuEtRzDmL7xs2C6RYt862k2Juobexf8V6bwtFX7Jg5vHztfc+lalwALcoaC47H Gnqop19mVu5sVhHIjakB =jxwX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (4)
-
David Sterba -
Hannes Reinecke -
Jeff Mahoney -
Jiri Slaby