[Bug 2045708] Re: Improve debian/99-gce.rules to set schedulers based on disk
Chloé Smith
2045708 at bugs.launchpad.net
Thu Jan 11 02:29:26 UTC 2024
** 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]
- * 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.
+ * This can also be done independently with a PPA hooked into CPC's bootstrap
+ scripts (kajiya's PPA here: [0])
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
+ [0]: 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:
Fix Released
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.
[ 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.
* This can also be done independently with a PPA hooked into CPC's bootstrap
scripts (kajiya's PPA here: [0])
If all the testing indicates that the image containing the new package
is good, verification is considered finished.
[0]: 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