[Bug 2045708] [NEW] Improve debian/99-gce.rules to set schedulers based on disk

Chloé Smith 2045708 at bugs.launchpad.net
Wed Dec 6 01:13:36 UTC 2023


Public bug reported:

We should reduce the `udev` rule scope here and change I/O scheduler.
The previous `udev` rule was drastically reducing the bootspeed on SSD
backed instances, as the `noop` scheduler is pretty old school.

I did pretty extensive experimentation and found that swapping to "none"
in this file yielded the best results on HDD instances (>10s improvement
in boot time on average). Letting SSD's just roll independently also
seemed to give the best speeds.

[ Test Plan ]

 * I built test GCP images with this file changed as proposed [0]
   * This can be done with a PPA hooked into CPC bootstrap scripts (kajiya's here: [1])

[ Where problems could occur ]

 * I can't see any regressions happening as we're moving _from_ `noop` _to_ not using a scheduler at all
   (`none`), which was the original behaviour before this file was introduced.

SRU
====

[ Impact ]

 * If an end user launches an Ubuntu instance in GCE backed with a HDD, no
   scheduler will be used natively.

 * This package is provided upstream by Google themselves, and is part of a
   collection of tools and that ensures that the Ubuntu images published to GCE
   run properly on the platform.

[Test Case]

When this package lands in -proposed, the following will happen:

 * an image built with this package from -proposed will be built for GCE and
   published in the `ubuntu-os-cloud-image-proposed` project
 * The image will go through CPC's own CTF framework, and assuming it passes
   will be handed to the Google team to perform their own verification.

If all the testing indicates that the image containing the new package
is good, verification is considered finished.

[0]: https://code.launchpad.net/~kajiya/ubuntu/+source/gce-compute-image-packages/+git/gce-compute-image-packages/+merge/455766
[1]: https://launchpad.net/~kajiya/+archive/ubuntu/gce-compute-image-packages

** Affects: gce-compute-image-packages (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  We should reduce the `udev` rule scope here and change I/O scheduler.
  The previous `udev` rule was drastically reducing the bootspeed on SSD
  backed instances, as the `noop` scheduler is pretty old school.
  
  I did pretty extensive experimentation and found that swapping to "none"
- in this file yeilded the best results on HDD instances (>10s improvement
+ in this file yielded the best results on HDD instances (>10s improvement
  in boot time on average). Letting SSD's just roll independently also
  seemed to give the best speeds.
  
  [ Test Plan ]
  
-  * I Built test GCP images with this file changed as proposed [0]
-    * This can be done with a PPA hooked into CPC bootstrap scripts (kajiya's here: [1])
+  * I Built test GCP images with this file changed as proposed [0]
+    * This can be done with a PPA hooked into CPC bootstrap scripts (kajiya's here: [1])
  
  [ Where problems could occur ]
  
-  * I can't see any regressions happening as we're moving _from_ `noop` _to_ not using a scheduler at all 
-    (`none`), which was the original behaviour before this file was introduced.
+  * I can't see any regressions happening as we're moving _from_ `noop` _to_ not using a scheduler at all
+    (`none`), which was the original behaviour before this file was introduced.
  
  SRU
  ====
  
  [ Impact ]
  
-  * If an end user launches an Ubuntu instance in GCE backed with a HDD, no scheduler will be used 
-    natively.
-  
-  * This package is provided upstream by Google themselves, and is part of a collection of tools and that 
-    ensure that the Ubuntu images published to GCE run properly on the platform.
+  * If an end user launches an Ubuntu instance in GCE backed with a HDD, no 
+    scheduler will be used natively.
+ 
+  * This package is provided upstream by Google themselves, and is part of a 
+    collection of tools and that ensures that the Ubuntu images published to GCE 
+    run properly on the platform.
  
  [Test Case]
  
  When this package lands in -proposed, the following will happen:
  
-  * an image built with this package from -proposed will be built for GCE and published in the `ubuntu-os- 
-    cloud-image-proposed` project
-  * The image will go through CPC's own CTF framework, and assuming it passes will be handed to the Google 
-    team to perform their own verification.
+  * an image built with this package from -proposed will be built for GCE and 
+    published in the `ubuntu-os-cloud-image-proposed` project
+  * The image will go through CPC's own CTF framework, and assuming it passes 
+    will be handed to the Google team to perform their own verification.
  
  If all the testing indicates that the image containing the new package
  is good, verification is considered finished.
+ 
+ [0]: https://code.launchpad.net/~kajiya/ubuntu/+source/gce-compute-image-packages/+git/gce-compute-image-packages/+merge/455766
+ [1]: https://launchpad.net/~kajiya/+archive/ubuntu/gce-compute-image-packages

** Description changed:

  We should reduce the `udev` rule scope here and change I/O scheduler.
  The previous `udev` rule was drastically reducing the bootspeed on SSD
  backed instances, as the `noop` scheduler is pretty old school.
  
  I did pretty extensive experimentation and found that swapping to "none"
  in this file yielded the best results on HDD instances (>10s improvement
  in boot time on average). Letting SSD's just roll independently also
  seemed to give the best speeds.
  
  [ Test Plan ]
  
-  * I Built test GCP images with this file changed as proposed [0]
+  * I built test GCP images with this file changed as proposed [0]
     * This can be done with a PPA hooked into CPC bootstrap scripts (kajiya's here: [1])
  
  [ Where problems could occur ]
  
   * I can't see any regressions happening as we're moving _from_ `noop` _to_ not using a scheduler at all
     (`none`), which was the original behaviour before this file was introduced.
  
  SRU
  ====
  
  [ Impact ]
  
-  * If an end user launches an Ubuntu instance in GCE backed with a HDD, no 
-    scheduler will be used natively.
+  * If an end user launches an Ubuntu instance in GCE backed with a HDD, no
+    scheduler will be used natively.
  
-  * This package is provided upstream by Google themselves, and is part of a 
-    collection of tools and that ensures that the Ubuntu images published to GCE 
-    run properly on the platform.
+  * This package is provided upstream by Google themselves, and is part of a
+    collection of tools and that ensures that the Ubuntu images published to GCE
+    run properly on the platform.
  
  [Test Case]
  
  When this package lands in -proposed, the following will happen:
  
-  * an image built with this package from -proposed will be built for GCE and 
-    published in the `ubuntu-os-cloud-image-proposed` project
-  * The image will go through CPC's own CTF framework, and assuming it passes 
-    will be handed to the Google team to perform their own verification.
+  * an image built with this package from -proposed will be built for GCE and
+    published in the `ubuntu-os-cloud-image-proposed` project
+  * The image will go through CPC's own CTF framework, and assuming it passes
+    will be handed to the Google team to perform their own verification.
  
  If all the testing indicates that the image containing the new package
  is good, verification is considered finished.
  
  [0]: https://code.launchpad.net/~kajiya/ubuntu/+source/gce-compute-image-packages/+git/gce-compute-image-packages/+merge/455766
  [1]: https://launchpad.net/~kajiya/+archive/ubuntu/gce-compute-image-packages

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gce-compute-image-packages in
Ubuntu.
https://bugs.launchpad.net/bugs/2045708

Title:
  Improve debian/99-gce.rules to set schedulers based on disk

Status in gce-compute-image-packages package in Ubuntu:
  New

Bug description:
  We should reduce the `udev` rule scope here and change I/O scheduler.
  The previous `udev` rule was drastically reducing the bootspeed on SSD
  backed instances, as the `noop` scheduler is pretty old school.

  I did pretty extensive experimentation and found that swapping to
  "none" in this file yielded the best results on HDD instances (>10s
  improvement in boot time on average). Letting SSD's just roll
  independently also seemed to give the best speeds.

  [ Test Plan ]

   * I built test GCP images with this file changed as proposed [0]
     * This can be done with a PPA hooked into CPC bootstrap scripts (kajiya's here: [1])

  [ Where problems could occur ]

   * I can't see any regressions happening as we're moving _from_ `noop` _to_ not using a scheduler at all
     (`none`), which was the original behaviour before this file was introduced.

  SRU
  ====

  [ Impact ]

   * If an end user launches an Ubuntu instance in GCE backed with a HDD, no
     scheduler will be used natively.

   * This package is provided upstream by Google themselves, and is part of a
     collection of tools and that ensures that the Ubuntu images published to GCE
     run properly on the platform.

  [Test Case]

  When this package lands in -proposed, the following will happen:

   * an image built with this package from -proposed will be built for GCE and
     published in the `ubuntu-os-cloud-image-proposed` project
   * The image will go through CPC's own CTF framework, and assuming it passes
     will be handed to the Google team to perform their own verification.

  If all the testing indicates that the image containing the new package
  is good, verification is considered finished.

  [0]: https://code.launchpad.net/~kajiya/ubuntu/+source/gce-compute-image-packages/+git/gce-compute-image-packages/+merge/455766
  [1]: https://launchpad.net/~kajiya/+archive/ubuntu/gce-compute-image-packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/2045708/+subscriptions




More information about the foundations-bugs mailing list