Setting Kernel Parameters - Sequencing Dependancy?

Support & Help Requests
,
1

After scanning many fora discussing kernel parameter settings for optimization, I've seen repeated references to the inter-dependency between the parameters.

Can someone point me to a reference (URL ?) that would provide what, for lack of relevant vocabulary, would be the

  • "precedence" list (which parameter dominates others), or
  • the "logical sequencing" list (context-defining/pre-requisites first, tuning/optimizing/overrides last),

so that I could define those settings, in proper order (if there is such a required order) in the sysctl.conf file knowing that the resulting state will show that I do, in fact, have the degree of control that, as an end-user, I think I am getting, ... and that the OS is behaving in the manner that I was trying to achieve.

In addition to that, can someone provide a reference to what is the dependency tree/mesh applicable to those parameters, in such a way that it also shows the (again, forgive my lack of proper vocabulary) "direction" and "sensitivity" of that influence of any given parameter on others with which there is an inter-dependency.

If such as the above are not readily available, I believe that if such were compiled, it would do both:

  • allow end-users to "tame" their machines with greater confidence and ease, and
  • allow aspiring-contributors to more quickly assimilate the complexity of the kernel code, and (in my limited view) offer developers better visibility of what might need further attention. Just a thought.

Thank you in advance for the hints/references.

----------- (addition) -----------
Does the sequence of current parameter state reported by sysctl -a (without that having been explicitly stated) provide that built-in precedence list?

----------- (addition) -----------
FYI for the community,

I came across this reference to the memory-management specific component of the kernel. I have yet to dig it to see if they have what I am looking for.

For the more adventurous, there is this link to https://kernelnewbies.org/ to help guide digging into customization of the kernel.

Regardless, I am sure these would be helpful to many who are new to the kernel stuff.

2

Hi Eric :slight_smile:

I hope you have some spare time because this post turned out to be a bit on the long side :wink:

  1. If you want to optimize it, what do you want to optimize ?
    latency ? responsiveness ? data throughput ? Boot time ? RAM use ?
    Some of these goals are mutually exclusive so deciding what you consider to be the most desirable aspects is of utmost importance.

  2. Not everything you read on fora is correct, some of it is half understood by the writers themselves or just plain wrong, especially when they are talking about tweaking kernelparameters to optimize a desktop system. However, there are some gains to be had in some areas outside the kernel.

  3. I've never encountered inter-dependency between kernel parameters but I might have overlooked something. Could you elaborate on that ?

There is no precedence because there is no overlap.
There is, however, a hierarchical structure which is mirrored in the name of the parameters themselves.

Also , there are only a few parameters that potentially may have some influence on each other in certain cases ( think of vm.swappiness versus vm.vfs_cache_pressure ) but there is no direct relation nor precedence.

The parameters in sysctl are declarative, not sequentially bound.
The kernel decides which parameter is read first, the order that you provide these parameters does not matter.

When needed (or forced), the sysctl list is loaded into a hierachical kernelstructure in one go. You can access this structure through the virtual proc filesystem.

find /proc/sys

Remember that what you see here are not files but internal kernelvariables.
It is represented as files to make them accessible from userspace.

This is only the virtual filesystem of the kernelvariables, but we have also a virtual filesystem to access driver parameters which I often use:

find /sys

Think of things like GPU fancontrol of your AMD RX580 discrete GPU unit, or things like LCD backlight on laptops. Everything is in this tree.

There is none.

I'll explain:
You are asking about logical sequencing which is outside the scope of the kernel. What you probably are looking for is the init system which runs in userspace and is not part of the kernel.

Let's be a bit pedantic to make some clear distinctions:
The name of the base operating system is GNU, it contains:

  1. A bootloader (in our case: GRUB2)
  2. A kernel ( in our case: Linux)
  3. The init system (in our case: systemd )
  4. A pretty abundant collection of GNU operating system commands.

The whole graphical user interface stack, which runs on top of that, is not necessarily a part of the operating system although all desktop systems have one:
The GUI stack consists of:

  1. a display manager (in our case: lightDM)
  2. a graphical local server (in our case: X11)
  3. a window manager ( in our case: marco)
  4. optionally a compositor (in our case selectable between: Xpresent, Picom or Compiz)
  5. and maybe a desktop environment (in our case MATE).

You probably might want to know the bootsequence: ( BIOS -> bootsector -> bootloader -> kernel+drivers+filesystem -> optionally more drivers -> initsystem -> displaymanager -> graphical-server -> desktop-environment )

----quote (undisclosed source)----------
"Allowing users what ?? Are you mad ?? Do you have the slightest glimpse of an idea of how much damage they might cause ?? We are talking about users you know !! The ones with two braincells that are still searching for the "Any key" since the 1980's . And you want me to hand them the administrator passwords ?? Giving a monkey a handgrenade is a less lethal option, until he figures out how to remove the pin ofcourse.
----end-quote----

Now, on a more serious note:

I think you got the wrong mental picture; there is nothing for end users to "tame" in the kernel, you are barking up the wrong tree here.

  1. I understand your sentiment but this is GNU/Linux, not MS-Windows. Things work structurally quite differently under the hood and on kernel level there may be at most one or two things to tweak, but that is about it.

  2. You can not optimize the system if you don't have a good mental picture of how the system works. Most users, including educated ones, wouldn't have a clue what to tweak in the first place and, more impotant, what not to tweak.

  3. You say that you want to optimize the kernel but as a matter of fact you really dont want that (besides maybe 1 or 2 parameters). The kernel is already optimized as it is. You might, however, tweak other parts of the GNU operating system.

  4. Again, it is preferrable to leave the kernelparameters unchanged, especially if you don't fully understand what every parameter actually does and what the consequences are when changing them. You would not be the first to discover that what you think as optimization would turn out as exactly the opposite of what you intended.

No, there is none. At least not in the kernel realm.

What you probably really want is to examine /etc/systemd/system for sequential evens during boot. Again, this has nothing to do with the kernel.

You would probably be surprised that the init system 'systemd' starts most of the needed services and actions in parallel and solving most of the sequential dependecies automatically.

BUT: Most is not all. You will find sequential information in the systemd unit files for every legacy service i.e. practically every interdependent service that is not socket bound.

So if you want (to compile) a list of what is sequentially started and interdependent, start reading here:

/lib/systemd/system/default.target

and from here follow the references to the other unit files (multi-user.target , basic.target , sysinit.target etc, etc, etc ). This will provide you with the list of "logical sequencing"

I could probably give a more concise answer if i could understand what you mean by "direction" and "sensitivity". The wording is quite vague and in the used context it can mean practically anything.

3 Likes
3

Thank you, @tkn.

I thank you for this very concise overview of sequencing/hierarchy of the OS/Desktop setup. I am sure many out there will find that just as helpful for putting things properly into the overall context.

I've seen that quote before. I feel that the perspective behind it lacks the respect for those who have substantial sysadmin experience for other OSs but are looking to expand their mastery into the domain of the Linux OS.

From my own experience, I feel there should be a "lockdown" function that prevents ANY and ALL changes to the OS until someone with the admin password releases that lock to do something.

As it is, given my own experience, I have a root-access shell window open at all times and use it almost constantly in parallel with my normal user GUI session. I've had the infrequent problematic mod, and never a change that forced a rebuild. So that quote is definitely "over-the-top" IMHO.

Very good info, but I haven't had a desire to go tweak the boot sequence since Ubuntu 14.04.

I looked at the contents there, and I don't see anything that is suggestive of a "sequence-directing" config file, nor does the age of the files/directories in that seem to offer evidence of a boot sequencing (at least that I can recognize). Since systemd does things in parallel (a lot), I'm not sure where one could find a user-oriented "specification" of systemd's "boot-order sequencing" of every service that is required for the core OS, and where, in that order, the sequencing of the optional services, if enabled, are interjected.

This parameter inter-play is more along the lines of what I was looking for.

I've been familiar with, and making use of that for a while now, for various things.

I've never really looked at this facet of the OS, because nothing prompted me to go dig into that. Maybe I should delve into it to see if there is anything there that would be of benefit.

Having looked at the contents of /sys/*, I don't see any huge desire to mess with those except for

  • the suspend/resume for my desktop computer (tried and failed many attempts at making that work),
  • getting my 3DConnexion SpaceNavigator ball/mouse to stop generating endless garbage error messages in the syslog, or
  • better fine-control over my multiple in-box cooling fans.

If you're willing to clarify, I am curious as to what I might be able to "tweak" under /sys/kernel that would be to my advantage, if anything. If nothing, then I'll not bother to look at those as targets for this "monkey with a handgrenade" !

Thank you for sharing your knowledge and willingness to assist others.

4

Hi Eric, :slight_smile:

I have the impression that I do not fully understand you and vice versa
so lets try to be as clear and concrete as possible in this conversation.

Oh yes ofcourse it is, it is from an old regional comedy show.

I gathered that you, as a sysadmin, would immediately recognize it as such.
Sorry that it inconvenienced you instead. My sincere apologies.

I guess you'll probably be wondering how I already knew that you were a sysadmin.

Well, as a fellow (ex-)system (non-windows) administrator i know that only MS-Windows sysadmins (oh, and MCSE-ers) are calling computer-owners "end-users" so I knew immediately your origin and thought you would be in on the joke :slight_smile:
Really , sorry again.

That is joke, right ? :cold_sweat:

Well, let's first get some misunderstandings out of the way:

But you also asked

Which confuses me a bit because, from my point of view in the context of a GNU/linux platform, that looks like a contradiction.

That is because ist doesn't exist as a config file. It exists as a collection of config snippets. Each snippet has a directional clue like "start before this" or "start after that" and only when it is sequence dependent.

You would think that such a setup is an uncontrollable chaos but if you look again you will see directories with names ending in .target . You can consider targets as a kind of sysVinit runlevels. Each "target" directory contains ( links to ) the snippets it needs to start the services it wants. The main target where systemd starts the services is the default.target which is often a softlink to either multiuser.target or graphical.target

The kernel has absolutely no part in this

You can find the whole design idea on the site of the author here
And it is extensively documented here

ofcourse not, bootsequencing based on file-datetime-stamp would go corrupt immediately after the first filechange.

The core-OS is the bootloader, kernel, driver, initsystem and userland tools.
None of those require any services to run.

Right after the kernel is loaded and running, the kernel starts the init system which starts the services
(there is more to it than this since systemd was introduced but let's not go there at the moment.)

Please elaborate.

Ok, that means that drivers and internal hardware can be regarded as outside the scope of this topic, that slims it down a bit.

To be honest: You will find nothing within your scope of interest in that virtual directory.
Although /sys in interesting, /sys/kernel is not.

Look, its seems a bit odd to me that, considering optimization, the kernel is the only part that you are interested in, while it is the last part that needs it.

Only in extreme or cramped setups you would be looking there, like in
high availability clusters, supercomputers or the other end of the spectrum: routers, switches and modems.

But anyway, that is not for me to decide so I will help you where I can.

The conclusion of your post gave the impression that you felt belitteled by me, probably because my extensive listing of bootsequence and such.
My apologies, that is not what I meant.

Since I have no clue what you precisely were asking for, I was hoping you would use my listing of things as a template to point out on witch part your question lies.

My sincere apologies :slight_smile:

If you have any questions, please let me know.

2 Likes
5

Thank you again, @tkn. I very much appreciate the time and patience you took in writing that response. I try not be funny or sarcastic in my posts because ...

  • I'm not very good at it, and
  • sarcasm isn't my thing.
  • I do try to use similes, but they sometimes flop, as seems to be the case with my reflecting back the "monkey" reference.

Honestly, I didn't take exception with any of what you referenced or stated. I did not take anything as intending to belittle me, either. Not sure how my response may have conveyed that, but if it did, it is I who must apologize for my lack of mastery in delivery of my intended message.

If you are curious, here's my profile on StackOverflow.

When I talk about stuff, I try to tackle it first at the conceptual level, trying to home in "strategically" on the area that needs to be tackled, and only when I have that pinned down, I then do the "tactical" for micro-analysis and intervention.

During my career, I always described myself as a SysAdmin with a User-Attitude. That might explain a bit of the "split-personality" in my wording and detail of my questions. ::

No joke. I would feel naked/hamstrung without that open root terminal session.

(This was the main intent of my original query.)
That refers to, if relevant and applicable, any sequencing that might need to be imposed on the placement of the variable assignment lines in the sysctl.conf file, given that some factors influence others. My intent is to place all parameters not impacted by sequencing at the top of the file, followed by all impacted by others in the proper order at the bottom of the file, with those I want to more-intensely controlled last, and those of lower-priority to me preceding those, again depending on the degree to which they need lesser control or fine-tuning.

I will have to revisit the contents of that, and the guts of the targets, and try to better understand what the various files are specifying before I can comment further. (systemd threw me off my game, which was all SysV init based. :: I haven't quite recovered from that, choosing instead to focus my energies elsewhere.)

I am very grateful for those links. Looks like a lot to take in but it will help to "grok" it all.

I made usage of the quoted description because it was fitting, given that I have been know to delve into dangerous territory in sysadmin, against the advice of others. I just happen to be a "monkey" whose intelligence has been raised much higher than the norm of that species, kind of like those in the two movies, Virgil in "Project X" and Pericles in "Planet of the Apes (2001)". So, no, I had not even an awareness of a gestalt that anything you said could have been the seed for anything demeaning. You can rest assured on that point.

1 Like
6

Hi, @ericmarceau :slight_smile:

( Usual disclaimer: please note that I'm just another Forum user here, I'm NOT an Ubuntu Developer and/or Ubuntu MATE Developer and/or MATE Developer ).

If you really wish to "tweak" performance settings (including the "sysctl" stuff that changes kernel parameters at runtime), I guess that one possibility is to install the "tuned" package with is associated with the "TuneD" service / daemon. You may find documentation about it at the following web page in the "Ubuntu Server" documentation:

https://ubuntu.com/server/docs/tuned

For easier reference, I will now quote here most of the text that appears in that web page:

https://ubuntu.com/server/docs/tuned

"TuneD

TuneD [https://tuned-project.org/ ] is a service used to tune your system and optimise the performance under certain workloads. At the core of TuneD are profiles, which tune your system for different use cases. TuneD is distributed with a number of predefined profiles for use cases such as:

  • High throughput
  • Low latency
  • Saving power

It is possible to modify the rules defined for each profile and customise how to tune a particular device. When you switch to another profile or deactivate TuneD, all changes made to the system settings by the previous profile revert back to their original state.

You can also configure TuneD to dynamically react to changes in device usage and adjust settings to improve the performance of active devices and reduce the power consumption of inactive devices.

Almost all tunable parameters can be good for one and bad for another type of workload or environment. Not even the goal of tuning is the same for everyone; do you want to improve latency, throughput, thermal or work-per-power? The system defaults generally aim for a good compromise on all of these, no matter what you will do with your system. The same is true for the TuneD profiles - they are only suggestions and starting points for a few named workload categories that allow you to react dynamically. But those can’t be perfect either - the more you know about your workload, your system and what you want to achieve with your tuning, the more you’ll be able to improve it to suit your needs.

Static vs. dynamic tuning

TuneD can perform two types of tuning: static and dynamic.

  • Static tuning mainly consists of applying predefined sysctl and sysfs settings and the one-shot activation of several configuration tools such as ethtool.
  • In dynamic tuning, it watches how various system components are used throughout the uptime of your system. TuneD then adjusts the system settings dynamically based on that monitoring information. For example, the hard drive is used heavily during startup and login, but is barely used later when the user is mainly working with applications (e.g. web browsers or email clients). Similarly, the CPU and network devices are used differently at different times. TuneD monitors the activity of these components and reacts to the changes in their use.

By default, dynamic tuning is enabled. To disable it, edit the /etc/tuned/tuned-main.conf file and change the dynamic_tuning option to 0. TuneD then periodically analyses system statistics and uses them to update your system tuning settings. To configure the time interval in seconds between these updates, use the update_interval option. After any change in this configuration file, the systemd service needs to be restarted.

Profiles

TuneD works with profiles, which are configuration files listing the tuning plugins and their options. Many predefined profiles are already shipped with the TuneD package, you can see them in /usr/lib/tuned. After installing the TuneD package, one can also use the tuned-adm list command to get a brief summary of all of the available profiles.

Once the package is installed in a system, a profile is activated by default depending on the environment. These are the default profiles for each type of environment:

Environment Default profile
Compute nodes throughput-performance
Virtual Machines virtual-guest
Containers default
Other cases balanced

Available profiles

The list of available profiles can be found using the following command:

root@tuned:~# tuned-adm list
Available profiles:
[...]

You can also check which profile is enabled:

root@tuned:~# tuned-adm active
Current active profile: virtual-guest

You can see the recommended profile:

root@tuned:~# tuned-adm recommend
virtual-guest

And you can switch to another profile:

root@tuned:~# tuned-adm profile default
root@tuned:~# tuned-adm active
Current active profile: default

Customising a profile

For some specific workloads, the predefined profiles might not be enough and you may want to customise your own profile. In order to do that, you should follow these steps:

  • Inside /etc/tuned, create a directory with the name of your new profile.
  • Inside the newly created directory, create a file called tuned.conf.
  • Write your custom configuration in the tuned.conf file.

After that, the new profile will be visible by TuneD via the tuned-adm list command. This is a simple example of a customised profile (it could be created in /etc/tuned/custom-profile/tuned.conf):

[main]
include=postgresql

[cpu]
load_threshold=0.5
latency_low=10
latency_high=10000

In the [main] section, the include keyword can be used to include any other predefined profile (in this example we are including the postgresql one).

After the [main] section, the list of plugins (ways of tuning your system) can be introduced, with all the options (here, there is just one plugin called cpu being used). For more information about the syntax and the list of plugins and their options, please refer to the upstream documentation. [ https://github.com/redhat-performance/tuned/tree/master/doc/manual/ ]

(...) "

I hope this helps :slight_smile:

2 Likes
7

Thank you, @ricmarques,

That reference you offered might prove interesting as a framework for a more disciplined environment to capture, document, and deploy the "final set" of tuned kernel parameters for various context "profiles". Thank you very much!

However, since I don't see a specific reference to "standalone desktop computer", which I never seem to find, from all the sites and fora that discuss "performance" or "tuning", it looks like I will need to keep digging until I find specific recommendations for various "desktop user application profiles".

To expand on that, I view the following as contexts-frames for some of those different "desktop user application profiles".

Context-Frame Categories (my perception):
H1. Limited-RAM (4GB and below), No-SSD, disk SWAP
H2. Limited-RAM (4GB and below), No-SSD, RAM-only SWAP
H3. Limited-RAM (4GB and below), SSD root, others on disk
H4. Limited-RAM (4GB and below), SSD root, others on disk, RAM-only SWAP
H5. Limited-RAM (4GB and below), SSD root and data partitions
H6. Performance-RAM (16GB-32GB), No-SSD
H7. Performance-RAM (16GB-32GB), No-SSD, RAM-only SWAP
H8. Performance-RAM (16GB-32GB), SSD root, others on disk
H9. Performance-RAM (16GB-32GB), SSD root, others on disk, RAM-only SWAP
H10. Performance-RAM (16GB-32GB), SSD root and data partitions
H11. Industrial-RAM (64GB+), No-SSD
H12. Industrial-RAM (64GB+), No-SSD, RAM-only SWAP
H13. Industrial-RAM (64GB+), SSD root, others on disk
H14. Industrial-RAM (64GB+), SSD root, others on disk, RAM-only SWAP
H15. Industrial-RAM (64GB+), SSD root and data partitions

As for the "Desktop User Application Profiles", here's my suggested list of the breakdown:
A1. Personal - Productivity (i.e. Office; eMail, Browser; Home Accounting; low-end gaming)
A2. Personal - Developer (i.e. IDE; Software Development; Virtual Machine Sandbox Environment for Testing)
A3. Personal - Performance (i.e. Internet-based Multi-Player Games with Real-Time 3D Graphics)
A4. Business - Productivity (i.e. Office, eMail, Browser, Host-based Services, DataBase Interraction/Reporting, Point-of-Sale, Customer Care)
A5. Business - Performance (i.e. Software Development; Business Statistical Analyses and Reporting; Business/Scientific Modelling/Simulation; Research and Business Intelligence)
A6. Business - Extreme (NCSA modelling of weather/ocean currents/climate; Cloud Computing; Supply-Chain Operations and Dashboards)

That gives you an idea of my abstract thinking on the "context-framing" of the tuning problem (yes, it is complex and wide-ranging, but unless "boundaries" are defined for those "vertical markets", people can't define a well thought-out plan of attack to "divide and conquer" the problem of tuning for each of those contexts which, for me are "sensible" permutations of the above 2 groupings. Making use of such clearly-spelled-out permutations would help people to self-identify and label their own "context-permutation", and absolutely make it easier for various developers, trainers and support people to correctly assess and respond to requests for each such stated "context permutation".

I hope that makes sense to you and everyone else in the community.

Given that, my current focus is on the "context-frame" defined for each of

  • [H1] + [A1]
    (intended for converting and massaging PDFs into personal-styled HTML/EPUB), and
  • [H1] + [A2]
    (intended for developing limited 3D-visualization of geodesic structures, and structural analysis thereof).

I would expect to transition from one to the other whenever the focus of my activities changes. The quick-flip by applying pre-defined sets of parameters would be trivial.

I think that type of characterization, of my focus of interest, should clarify the "what" of my interests, such that it would, in my view, help community members who have both, the experience and the willingness to help, can help me define such focused profiles. Once such a profile (or profiles) could be confirmed by a group of willing members (does 20-50 individual user deployments of such parameter profiles seem reasonable?), those could be formally incorporated into the set of distinct, verified good profiles. Whether those are collected and held by a toolset such as "tuned", or simply as part of the "tweak" tools that various distros are now offering, is clearly up for discussion, but not part of my "ask" from this posting.

Thank you, to all community members, who were patient enough to fully read that qualified abstraction of my needs and wants. I look forward to might come out of that further outlining of my "wants".

8

Hi again, @ericmarceau :slight_smile:

You wrote:

Actually - although it is true that the https://ubuntu.com/server/docs/tuned article doesn't specifically mention it - one of the available "tuned" profiles is called "desktop".

The manpage of "tuned-profiles" - available from the command man tuned-profiles and also available online, for Ubuntu 22.04 ("Jammy Jellyfish"), at "Ubuntu Manpage: tuned-profiles - description of basic tuned profiles" - https://manpages.ubuntu.com/manpages/jammy/en/man7/tuned-profiles.7.html - includes, among other useful information, the following for the desktop use case scenario:

" (...) PROFILES

At the moment we're providing the following pre-defined profiles:

balanced
It is the default profile. It provides balanced power saving and performance. At
the moment it enables CPU and disk plugins of tuned and it makes sure the
conservative governor is active (if supported by the current cpufreq driver). It
enables ALPM power saving for SATA host adapters and sets the link power management
policy to medium_power. It also sets the CPU energy performance bias to normal.
It also enables AC97 audio power saving or (it depends on your system) HDA-Intel power
savings with 10 seconds timeout. In case your system contains supported Radeon
graphics card (with enabled KMS) it configures it to automatic power saving.
(...)
desktop
Profile optimized for desktops based on balanced profile. It additionally enables
scheduler autogroups for better response of interactive applications.
(...)"

Here's the full output of running the tuned-adm list command in a laptop computer running Ubuntu MATE 22.04 LTS ("Jammy Jellyfish"), after having installed the "tuned" package:

$ tuned-adm list
Available profiles:
- accelerator-performance     - Throughput performance based tuning with disabled higher latency STOP states
- atomic-guest                - Optimize virtual guests based on the Atomic variant
- atomic-host                 - Optimize bare metal systems running the Atomic variant
- balanced                    - General non-specialized tuned profile
- cpu-partitioning            - Optimize for CPU partitioning
- default                     - Legacy default tuned profile
- desktop                     - Optimize for the desktop use-case
- desktop-powersave           - Optmize for the desktop use-case with power saving
- enterprise-storage          - Legacy profile for RHEL6, for RHEL7, please use throughput-performance profile
- hpc-compute                 - Optimize for HPC compute workloads
- intel-sst                   - Configure for Intel Speed Select Base Frequency
- laptop-ac-powersave         - Optimize for laptop with power savings
- laptop-battery-powersave    - Optimize laptop profile with more aggressive power saving
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- mssql                       - Optimize for MS SQL Server
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- optimize-serial-console     - Optimize for serial console use.
- oracle                      - Optimize for Oracle RDBMS
- postgresql                  - Optimize for PostgreSQL server
- powersave                   - Optimize for low power consumption
- realtime                    - Optimize for realtime workloads
- realtime-virtual-guest      - Optimize for realtime workloads running within a KVM guest
- realtime-virtual-host       - Optimize for KVM guests running realtime workloads
- sap-hana                    - Optimize for SAP HANA
- sap-netweaver               - Optimize for SAP NetWeaver
- server-powersave            - Optimize for server power savings
- spectrumscale-ece           - Optimized for Spectrum Scale Erasure Code Edition Servers
- spindown-disk               - Optimize for power saving by spinning-down rotational disks
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: balanced
3 Likes
9

Thank you very much, @ricmarques!

That is the first concrete lead I've had on configuration tuning that was specifically addressing the desktop/workstation context!

It is unfortunate that it seems to be focused mostly on the variation of hardware profiles, but not so much on the variety of task-scope profiles for any one of those listed hardware profiles.

I will take some time to look at that in detail, try a few things out, before I get back to you, sometime next week, with an update on how things went.

In the meantime, if anyone else has suggestions/hints on where to find recommendations appropriate to those context-permutations that I mentioned earlier, I would welcome those avidly and gratefully.

Till then, @ricmarques , what you provided gives me some hope of a "deeply-researched" configuration that would be worthwhile trying out.

2 Likes