** Tags added: hw-specific
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1420544
Title:
Ubuntu instances on GCE should use NOOP scheduler
To manage notifications about this bug go to:
I uploaded a trusty update for this to the SRU review queue. Please test
the -proposed package once it is available to verify this. Thanks!
** Changed in: systemd (Ubuntu Trusty)
Status: Triaged = In Progress
** Changed in: systemd (Ubuntu Trusty)
Assignee: Martin Pitt (pitti) =
@Ben Howard: I'll upload that to trusty as soon as the current SRU gets
verified and into trusty-updates.
** Changed in: systemd (Ubuntu Trusty)
Assignee: (unassigned) = Martin Pitt (pitti)
** Changed in: systemd (Ubuntu Trusty)
Importance: Undecided = Medium
--
You received this bug
The updated udev rule is of course fine for an SRU. Marked for trusty
for now, please add more releases as desired. Keeping the linux task for
vivid onwards to change the default in the virtio kernel driver itself
(pending feedback from the kernel team).
** Package changed: ubuntu = linux
That's a bit better indeed. But I still wonder why that cannot be in
cloud-init or another cloud specific package? This is a rule that we
basically have to keep forever, it's never going to apply (and just
marginally slow down) on desktops or touch. And I'm not in a position to
determine when this
GCE is Google Compute Engine which is their cloud virtual machine
offering.
The rationale for the change is that Ubuntu by default uses deadline for
14.04+. Google has requested that we switch over to noop for
performance reasons.
Would pegging the rule like so work better?
SUBSYSTEM==block,
+apw for comment on #5
Changing the virtio driver makes sense to me, however, I wonder if a
wholesale change might be bad.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1420544
Title:
Ubuntu
This is an unconditional rule which will just second-guess kernel
defaults everywhere, and it will not go to upstream either. Wouldn't it
make more sense to fix whichever kernel driver is responsible for this
device (or possibly QEMU) to pick a scheduler which is appropriate for
these virtual
Thank you for taking the time to report this bug and helping to make
Ubuntu better. It seems that your bug report is not filed about a
specific source package though, rather it is just filed against Ubuntu
in general. It is important that bug reports be filed about source
packages so that people
Since we are going to start rolling in all the cloud image secret saucy
done via udev, I've added a new rule set to start with.
This change is confirmed to work.
** Patch added: Debdiff of change
https://bugs.launchpad.net/ubuntu/+bug/1420544/+attachment/4316771/+files/deb.diff
--
You
10 matches
Mail list logo
