Uploaded image for project: 'Product Technical Learning'
  1. Product Technical Learning
  2. PTL-8240

RH442-94: Clarify scenarios for using "noop" scheduler

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Minor Minor
    • RH442 - RHEL 8 1 20190828
    • RH442 - RHEL 7 2 20150420
    • RH442
    • None
    • 8
    • en-US (English)

      URL:
      Reporter RHNID:
      Section: -
      Language: en-US (English)|
      Workaround:

      Description: Disk schedulers are introduced in chapter 8. It is mentioned that virtual guest disks (virtual disks) and SSDs use "noop", but there is no other clarification of "noop" scenarios. Fundamentally, any disk that is a logical device that comes from physical components on another system is a situation for using "noop". For example, SAN disks show up as LUNs locally, but any scheduling done locally is ignored by the RAID box back end and would be mitigated by caching controller reordering and back end (tray and controller) scheduling done outside of the RHEL operating system.

      As Randy Hamilton stated in an email: "Normally, on any of the san/nas setups that we have using EMC and netapp devices, it is recommended and practice to use NOOP. While the latency is not a very measurable improvement(IE access times), the biggest benefit is that it will use the memory/SSD cache far more when we offload that to the SAN/NAS itself. the EMC VNX devices we use tend to work much better with noop."

      The await times are decreased and unecessary processing (CPU activity that would be redundant) is eliminated.

              rht-avazquez Adolfo Vazquez (Inactive)
              rht-psweany Philip Sweany (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: