@lathiat:

> - Is there some specific hardware where scaling-driver=pcc-cpufreq
>   and scaling-governor=ondemand performs poorly. I have yet to run a
>   benchmark on my example hardware to find out.

Yes, we first started seeing this when deploying new Ubuntu Archive
servers where we had two servers in the same DC taking on the same
amount of traffic/requests. One was showing much higher load and
performing much worse than the other.

We brought up others in another DC and saw the same. The internal
ticket, RT#90571, has some details.

The specs differ with the one without issues being:

| economy - HP ProLiant DL380 G7

The ones that were showing issues are:

| hanger  - HP ProLiant DL360p Gen8
| steelix - ProLiant DL380 Gen9
| keeton  - ProLiant DL380p Gen8

By default, they're using the pcc-cpufreq but we also tried
acpi-cpufreq which didn't seem to have made any difference.

This led to us filing LP: #1579278 and the change to a piece of
software we use to deploy disabling the 'ondemand' CPU governor:

| https://bazaar.launchpad.net/~canonical-
sysadmins/basenode/trunk/revision/98

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1806012

Title:
  set-cpufreq: 'powersave' governor configuration sanity on ubuntu
  server

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  Whilst debugging 'slow instance performance' on a Ubuntu Bionic based
  cloud, I observed that the default cpu governor configuration was set
  to 'powersave'; toggling this to 'performance' (while in not anyway a
  particularly green thing todo) resulted in the instance slowness
  disappearing and the cloud performance being as expected (based on a
  prior version of the deploy on Ubuntu Xenial).

  AFAICT Xenial does the same thing albeit in a slight different way,
  but we definitely did not see the same performance laggy-ness under a
  Xenial based cloud.

  Raising against systemd (as this package sets the governor to
  'powersave') - I feel that the switch to 'performance' although
  appropriate then obscures what might be a performance/behavioural
  difference in the underlying kernel when a machine is under load.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.9
  ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
  Uname: Linux 4.15.0-39-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  Date: Fri Nov 30 10:05:46 2018
  Lsusb:
   Bus 002 Device 002: ID 8087:8002 Intel Corp. 
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub
   Bus 001 Device 002: ID 8087:800a Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. PowerEdge R630
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic 
root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt 
intel_iommu=on
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.3.4
  dmi.board.name: 02C2CP
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A03
  dmi.chassis.type: 23
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr:
  dmi.product.name: PowerEdge R630
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to