Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Blk-mq Is Almost Feature Complete & Fast With Linux 3.16

  1. #1
    Join Date
    Jan 2007
    Posts
    14,912

    Default Blk-mq Is Almost Feature Complete & Fast With Linux 3.16

    Phoronix: Blk-mq Is Almost Feature Complete & Fast With Linux 3.16

    Merged for the Linux 3.13 kernel was the multi-queue block layer allows for better SSD performance with reduced latency and by balancing I/O workload across multiple CPU cores and supporting multiple hardware queues. With the upcoming Linux 3.16 kernel, the "blk-mq" code is expected to be feature complete and deliver great performance...

    http://www.phoronix.com/vr.php?view=MTcwNzc

  2. #2
    Join Date
    Nov 2008
    Posts
    56

    Default

    I've been sticking with the 3.12.x longterm kernel, because of assorted issues and instability since the multi-queue block layer implementation. Maybe 3.16 will be the one that finally lets me move forward again.

  3. #3
    Join Date
    Mar 2012
    Posts
    320

    Default

    is it used by default or do I have to set something in /etc/fstab or so?
    is it used by default for ssd only? or also for hdd?

  4. #4
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by macemoneta View Post
    I've been sticking with the 3.12.x longterm kernel, because of assorted issues and instability since the multi-queue block layer implementation. Maybe 3.16 will be the one that finally lets me move forward again.
    Could you perhaps describe these kind of issue's? I have been issue's on btrfs filesystems with kernel 3.13 or higher. Reading some files causes the process to stall.

  5. #5
    Join Date
    Apr 2014
    Posts
    8

    Default

    3.13 had a perf regression as a result of the blk-mq patch, I wonder if this is finally going to be fixed in 3.16?

  6. #6
    Join Date
    Jun 2014
    Posts
    5

    Default

    Quote Originally Posted by Caleb View Post
    3.13 had a perf regression as a result of the blk-mq patch, I wonder if this is finally going to be fixed in 3.16?
    What perf regression?

  7. #7
    Join Date
    Jun 2014
    Posts
    5

    Default

    Quote Originally Posted by macemoneta View Post
    I've been sticking with the 3.12.x longterm kernel, because of assorted issues and instability since the multi-queue block layer implementation. Maybe 3.16 will be the one that finally lets me move forward again.
    Sorry, but that's just nonsense. Unless you are running on virtio-blk as your storage driver, blk-mq could not have caused any instability issues for 3.13 or later.

  8. #8
    Join Date
    Nov 2008
    Posts
    56

    Default

    Quote Originally Posted by Rexilion View Post
    Could you perhaps describe these kind of issue's? I have been issue's on btrfs filesystems with kernel 3.13 or higher. Reading some files causes the process to stall.
    Stalls mostly, as well as reduced responsiveness. I use btrfs, but the btrfs mailing list seems to indicate they're not btrfs related. It may be the result of btrfs switching worker threads to now use kernel workqueues. Whatever the cause, my systems run flawlessly on the 3.12.x kernels. I've checked various 3.13, 3.14, and 3.15rc kernels, and they all exhibit the issue across multiple systems (Intel and AMD).

  9. #9
    Join Date
    Jun 2014
    Posts
    5

    Default

    Quote Originally Posted by macemoneta View Post
    Stalls mostly, as well as reduced responsiveness. I use btrfs, but the btrfs mailing list seems to indicate they're not btrfs related. It may be the result of btrfs switching worker threads to now use kernel workqueues. Whatever the cause, my systems run flawlessly on the 3.12.x kernels. I've checked various 3.13, 3.14, and 3.15rc kernels, and they all exhibit the issue across multiple systems (Intel and AMD).
    What you want to do here is run a bisect between 3.12 and 3.13 and pinpoint exactly where the issue is. That is by far the most effective way to get the developers attention and get the issue fixed. Let me know if you need any help with doing the bisection. If you have already compiled a custom kernel, it's a trivial exercise. Especially if you can quickly vet or reject a given kernel after booting it.

  10. #10
    Join Date
    Nov 2008
    Posts
    56

    Default

    Quote Originally Posted by axboe View Post
    What you want to do here is run a bisect between 3.12 and 3.13 and pinpoint exactly where the issue is. That is by far the most effective way to get the developers attention and get the issue fixed. Let me know if you need any help with doing the bisection. If you have already compiled a custom kernel, it's a trivial exercise. Especially if you can quickly vet or reject a given kernel after booting it.
    I'm familiar with the process, but it takes days, sometimes over a week for the problem to occur. By the time I completed a bisect, 3.17 would be out. Odds are, someone will have corrected the issue, intentionally or not, by then.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •