tuned-2.4.0 released
by Jaroslav Skarvada
This is to announce tuned-2.4.0, a stable release.
Tuned is a tool that performs monitoring and adaptive configuration
of the system according to selected profile.
The 2.4.0 contains many bug fixes and also introduces new features.
Noteworthy changes since previous release:
- fixed traceback if profile cannot be loaded (rhbz#953128)
- powertop2tuned: fixed traceback if rewriting file instead of directory (rhbz#963441)
- daemon: fixed race condition in start/stop
- improved timings, it can be fine tuned in /etc/tuned/tuned-main.conf (rhbz#1028122)
- throughput-performance: altered dirty ratios for better performance (rhbz#1043533)
- latency-performance: leaving THP on its default (rhbz#1064510)
- used throughput-performance profile on server by default (rhbz#1063481)
- network-latency: added new profile (rhbz#1052418)
- network-throughput: added new profile (rhbz#1052421)
- recommend.conf: fixed config file (rhbz#1069123)
- spec: added kernel-tools requirement (rhbz#1073008)
- systemd: added cpupower.service conflict (rhbz#1073392)
- balanced: used medium_power ALPM policy
- added support for >, < assignment modifiers in tuned.conf
- handled root block devices
- balanced: used conservative CPU governor (rhbz#1124125)
- plugins: added selinux plugin
- plugin_net: added nf_conntrack_hashsize parameter
- profiles: added atomic-host profile (rhbz#1091977)
- profiles: added atomic-guest profile (rhbz#1091979)
- moved profile autodetection from post install script to tuned daemon (rhbz#1144067)
- profiles: included sap-hana and sap-hana-vmware profiles
- man: structured profiles manual pages according to sub-packages
- added missing hdparm dependency (rhbz#1144858)
- improved error handling of switch_profile (rhbz#1068699)
- tuned-adm: active: detect whether tuned deamon is running (rhbz#1068699)
- spec: removed active_profile from RPM verification (rhbz#1104126)
- plugin_disk: readahead value can be now specified in sectors (rhbz#1127127)
- plugins: added bootloader plugin (rhbz#1044111)
- plugin_disk: added error counter to hdparm calls
- plugins: added scheduler plugin (rhbz#1100826)
- added tuned-gui with profile editor
Download:
http://fedorahosted.org/releases/t/u/tuned/tuned-2.4.0.tar.bz2
Upstream homepage:
http://fedorahosted.org/tuned/
6 years, 6 months
[tuned] #49: Provide a way to disable dynamic updates per plugin
by fedora-badges
#49: Provide a way to disable dynamic updates per plugin
--------------------------+---------------------
Reporter: ework | Owner:
Type: enhancement | Status: new
Priority: major | Component: plugins
Version: 2.0 | Keywords: net
Blocked By: | Blocking:
--------------------------+---------------------
I use synergy to share a mouse & keyboard between my desktop and laptop.
Whenever I start to download something (for example a Fedora ISO), I lose
my connection for about 30 sec due to the ethernet interface speed change.
Even worse the download fails because the connection is lost for this
brief period of time. I'd suggest that at least this change doesn't occur
when on AC as a default policy, but for me personally a way to disable
dynamic updates per plugin without having to hack the python code would be
nice. I couldn't seem to find anywhere in the documentation that mentions
how to do this.
--
Ticket URL: <https://fedorahosted.org/tuned/ticket/49>
tuned <https://fedorahosted.org/tuned/>
A daemon that performs monitoring and adaptive configuration of devices in the system.
7 years, 9 months
tuned plugin to manage application tuning hints?
by Clark Williams
Jaroslav,
This is an attempt to firm up the rather vague discussion I had with
you on IRC. Hope it makes sense.
Currently, tuned manages system-wide tuning parameters for realtime
and NFV systems, mainly cpu isolation. That's fine for simple
deployments where we boot up, isolate some cpus, then start an
application that runs on those isolated cpus. It's not so good when we
start dealing with subsystems like Open VirtualSwitch (ovs) or stacks
like OpenStack. Those components have their own startup logic and
could use application specific tuning directions, such as cpu
placement, scheduling policy/priority, IRQ placement, etc.
Essentially, I'm asking that we come up with a way for tuned to parse
a file (or files) that contain tuning keypairs, and then provide those
keypairs when asked. The tuning info would be in one place and tuned
could have some logic to verify that the tuning's don't conflict.
For example, let's say a system has 44 cores and using
tuned-profiles-nfv, we've specified that 8 of those cores should be
isolated (isolcpus=36-43). Additionally, we want to run ovs on four of
the cores and my-special-app on the other four, so we could have a
file somewhere that looks like this:
[ovs]
cpulist=36-39
policy=fifo
priority=20
[my-special-app]
cpulist=40-43
policy=fifo
priority=10
What I envision is the ovs startup logic querying tuned with the key
'ovs' and getting back the keypairs above, which it could then use
properly to place the ovs threads on the appropriate cpus at the
specified scheduling policy and priority. Ditto when the
my-special-app startup logic runs.
Additionally, we don't currently have a good way to add arbitrary
kernel parameters to the kernel command line. We can get isolcpus=
added via the tuned-profiles-{realtime,nfv} packages, but if you want
to add intel_idle.max_cstate= or rcu_nocb_poll, or a host of others,
you're off editing /etc/default/grub. It might be nice to have a file
section called 'boot', where you can add kernel command line
parameters and possibly IRQ affinity placement. Not a high priority
for me, but it might be nice to collect all this tuning info into one
place:
[boot]
isolcpus=36-43
irq_affinity= !${isolcpus}
params='debug intel_idle.max_cstate=1'
[ovs]
cpulist=36-39
policy=fifo
priority=20
[my-special-app]
cpulist=40-43
policy=fifo
priority=10
Bottom line is that I think I'm talking about a tuned plugin that
becomes a clearinghouse for tuning hints. The plugin parses the info,
checks to make sure that things like cpu lists and irqs all make
sense, possibly updates the grub config with info from the [boot]
section and then just replies when someone queries for info using a
particular key (e.g. 'ovs') with a list of the keypairs.
Thoughts?
Clark
7 years, 9 months