Hi Christian,
Thank you, yes I don't disagree with anything you said. There can be no
"one size fits all" and customizing performance tuning will always be
important but I will argue
1. There can be a "one size fits most" at least for desktop client
environments ("general optimization")
2. It may be surprising what "general optimization" entails given the
general lack of consideration to the psychological experience of the user.
Apple discovered this as a historical accident a few decades ago. I am no
fan of them, though, because they don't allow that customization. My wife
is dyslexic and uses a Mac for work that does not allow her to install and
use OpenDyslexic fonts in the OS because Apple has already "determined what
is best."
To ground the 2nd point above, I would give a hypothetical: trading 25ms of
latency/jitter for a 10% gain in throughput might seem like a no-brainer
from a benchmarking perspective. But when user psychology is factored in as
well as allowing for adequate default performance for the widest use cases
available, the tradeoff quickly becomes unacceptable. The "relatively
large" 10% throughput has very little relevance outside of benchmarking
whereas the 25ms of latency/jitter can make or break entire workflows and
usage scenarios from a user perspective covering a broad set of scenarios.
The only danger there is that people will compare "out of the box benchmark
performance" and say "this system is slower than that system!"
But I agree, now it's time for more discussion and input (including data)
from others. I'm glad that this discussion is occurring! I don't think I
have anything more to offer at this point.
ethan
On Thu, Jan 11, 2024 at 11:20 PM Christian Ehrhardt <
1833...@bugs.launchpad.net> wrote:
> Hi Etanay,
>
> I realize I maybe wrote too much :-/
> So I start with a TL;DR:
> AFAICS you are right in all you say, but I think there can not be "one
> right answer" anyway. Hence I'm trying to leave all parties their freedom
> of defining what is important to them and try to learn from them what
> impact irqbalance has to that.
>
>
> > Yes I was not arguing strictly against irqbalance, just trying
> > to ascertain some discussion parameters as well as parameters for data
> > collection.
>
> Yeah, I see that and didn't intend to rebut your statements either.
> Just push them a bit into potential context and POV of others.
>
>
> > I have not yet seen a coherent philosophy on what it means to "optimize
> > performance" with default settings that serve the greatest capacity of
> > server or desktop scenarios.
>
> That is true, but the reason for that is that you can only optimize for
> something like a workload or particular HW.
>
> The defaults are usually trying to be not too crappy for any possible
> thing that might happen on e.g. Ubuntu which is quite a scope.
>
> > In my humble opinion, data collection is useless without this
> > framework of understanding what it is we are trying to achieve
> > and why in terms of system performance. To me this is the deeper
> > unresolved issue, perhaps.
>
> I can see your point and would not even argue against. But this is
> (this is opinion and a bit of experience, not scientific proven
> truth) only the problem if we'd try to solve the singular global
> and always valid "is irqbalance good or bad" question.
>
> Thinking about it I think I'm even of the same opinion than you,
> but instead of standardizing excatly what we are trying to achieve
> (which to me feels like selecting a workload or HW as optimization
> target) I was trying to reach out to as many groups as possible
> so we can see what HW/workloads are important to them and how
> irqbalance might help or interfere with that.
>
> A bit like the old case where some clouds brought it up that it is
> conflicting in virtio-net on their substrate and to be disabled
> by default there (see Debian and also some Ubuntu cloud images).
>
> I have personally no hope in reaching a general "this is good / bad"
> without considering it per workload or HW environment.
>
> Hence my hope is that if we manage to get this variety of preferences
> of different parties and only then the impact of irqbalance to that
> we can make compartmentalized decisions.
> For example as some suggested, making it no more the default in
> Desktop, but keeping it in other cases.
>
> And this is just me trying to be helpful and drive this from being
> a dormant case to something useful, I do not pretend to have the
> masterplan or the solution yet :-)
>
>
> > I fear that systems are currently optimized by default for throughput.
> For
> > users, responsiveness (which can include but is not limited to
> throughput)
> > and latency may be more important psychologically
>
> Can I just say yes here, you go into lengths explaining (thanks) but I
> already agreed here :-)
>
> Yet - as true as that is - it is true for a set of workloads and hardware,
> but not for all that Ubuntu can be (as I outlined above neither decision
> could be true for all)
>
> > And power saving is important in global terms, as even small gains
> > multiplied over hundreds or thousands of deployments can have a
> > significant impact
>
> True as well, yet - again - most servers are often split by some virt
> solution to pay off by their price running at high utilization.
> There to reach density often people are ok to forfeit some latency
> for overall throughput and thereby density which saves power by
> having x% less systems active at all.
>
>
> P.S. I'm now waiting for further input by all of you that found the thread
> so far as well as hopefully
> some of all the teams, hardware manufacturers and clouds that I have
> connected to please think about this question.
>
> P.P.S. I'm drifting away of seeing a big deja-vu into my decade of
> Linux on mainframe performance - and density and performance and
> interfering workloads that invalidated all you knew when looking
> at just one ... and you know what the answer always was and still is:
> "it depends" as any performance engineer will love to tell you :-)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1833322
>
> Title:
> Consider removing irqbalance from default install on desktop images
>
> Status in Ubuntu on IBM z Systems:
> New
> Status in irqbalance package in Ubuntu:
> Confirmed
> Status in ubuntu-meta package in Ubuntu:
> Confirmed
>
> Bug description:
> as per https://github.com/pop-os/default-settings/issues/60
>
> Distribution (run cat /etc/os-release):
>
> $ cat /etc/os-release
> NAME="Pop!_OS"
> VERSION="19.04"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Pop!_OS 19.04"
> VERSION_ID="19.04"
> HOME_URL="https://system76.com/pop";
> SUPPORT_URL="http://support.system76.com";
> BUG_REPORT_URL="https://github.com/pop-os/pop/issues";
> PRIVACY_POLICY_URL="https://system76.com/privacy";
> VERSION_CODENAME=disco
> UBUNTU_CODENAME=disco
>
> Related Application and/or Package Version (run apt policy $PACKAGE
> NAME):
>
> $ apt policy irqbalance
> irqbalance:
> Installed: 1.5.0-3ubuntu1
> Candidate: 1.5.0-3ubuntu1
> Version table:
> *** 1.5.0-3ubuntu1 500
> 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
> 100 /var/lib/dpkg/status
>
> $ apt rdepends irqbalance
> irqbalance
> Reverse Depends:
> Recommends: ubuntu-standard
> gce-compute-image-packages
>
> Issue/Bug Description:
>
> as per konkor/cpufreq#48 and
> http://konkor.github.io/cpufreq/faq/#irqbalance-detected
>
> irqbalance is technically not needed on desktop systems (supposedly it
> is mainly for servers), and may actually reduce performance and power
> savings. It appears to provide benefits only to server environments
> that have relatively-constant loading. If it is truly a server-
> oriented package, then it shouldn't be installed by default on a
> desktop/laptop system and shouldn't be included in desktop OS images.
>
> Steps to reproduce (if you know):
>
> This is potentially an issue with all default installs.
>
> Expected behavior:
>
> n/a
>
> Other Notes:
>
> I can safely remove it via "sudo apt purge irqbalance" without any
> apparent adverse side-effects. If someone is running a situation where
> they need it, then they always have the option of installing it from
> the repositories.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+subscriptions
>
>
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1833322
Title:
Consider removing irqbalance from default install on desktop images
Status in Ubuntu on IBM z Systems:
New
Status in irqbalance package in Ubuntu:
Confirmed
Status in ubuntu-meta package in Ubuntu:
Confirmed
Bug description:
as per https://github.com/pop-os/default-settings/issues/60
Distribution (run cat /etc/os-release):
$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="19.04"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Pop!_OS 19.04"
VERSION_ID="19.04"
HOME_URL="https://system76.com/pop";
SUPPORT_URL="http://support.system76.com";
BUG_REPORT_URL="https://github.com/pop-os/pop/issues";
PRIVACY_POLICY_URL="https://system76.com/privacy";
VERSION_CODENAME=disco
UBUNTU_CODENAME=disco
Related Application and/or Package Version (run apt policy $PACKAGE
NAME):
$ apt policy irqbalance
irqbalance:
Installed: 1.5.0-3ubuntu1
Candidate: 1.5.0-3ubuntu1
Version table:
*** 1.5.0-3ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
100 /var/lib/dpkg/status
$ apt rdepends irqbalance
irqbalance
Reverse Depends:
Recommends: ubuntu-standard
gce-compute-image-packages
Issue/Bug Description:
as per konkor/cpufreq#48 and
http://konkor.github.io/cpufreq/faq/#irqbalance-detected
irqbalance is technically not needed on desktop systems (supposedly it
is mainly for servers), and may actually reduce performance and power
savings. It appears to provide benefits only to server environments
that have relatively-constant loading. If it is truly a server-
oriented package, then it shouldn't be installed by default on a
desktop/laptop system and shouldn't be included in desktop OS images.
Steps to reproduce (if you know):
This is potentially an issue with all default installs.
Expected behavior:
n/a
Other Notes:
I can safely remove it via "sudo apt purge irqbalance" without any
apparent adverse side-effects. If someone is running a situation where
they need it, then they always have the option of installing it from
the repositories.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+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
