Upstream commit adding this feature:
https://git.fedorahosted.org/cgit/tuned.git/commit/?id=bf42cb9ba3c39e1e5aec680f2fdc98c4a51666e5

Currently it is substitution for the rtctl tool, but there are small differences in the syntax (due to tuned specific internals).

Format for the rules is:

group.GROUPNAME=RULE_PRIO:SCHED:PRIO:AFFINITY:REGEX

where RULE_PRIO defines tuned priority of the rule. Rules are sorted according to priority. This is needed for inheritence to be able to reorder previously defined rule. For same RULE_PRIO, rules should be processed in the order there were defined (but this is Python interpreter dependant). To disable inherited rule for GROUPNAME use:

group.GROUPNAME=

SCHED must be one of:
  'f' for FIFO,
  'b' for batch,
  'r' for round robin,
  'o' for other,
  '*' means not to change.

AFFINITY is a hex number, see taskset(1) for details about number of CPUs. The '*' means not to change.

REGEX is Python regex. It must match against output of

ps -eo cmd

Any given process name may match more than one group. Default priority and scheduling policy are taken from the last matching regex.

You need to write 'group.' prefix before your group name. This is because there may be added other parameters to the plugin later.

Example of usage:

[scheduler]
group.kthreads=0:*:1:*:\[.*\]$
group.watchdog=0:f:99:*:\[watchdog.*\]

CCing mgrepl, tuned now calls chrt and taskset.

Improvements over rtctl tool:
- inheritance - group names can be inherited from ancestor profiles
- automatic revert of settings - on profile unload / change everything what was changed is reverted back to its initial state (before profile load). During the revert both PID and full process name are checked and both need to match for the revert to take action.

Regarding tuning of newly created processes I need to think a bit about it. Systemtap / LD_PRELOAD may bring performance penalty (for loads creating many processes - probably not typical loads). Other possibility is to poll e.g. each 10 seconds. There is already infrastructure for this that was used for dynamic tuning (already disabled in RHEL). This may be improved just to only run monitors for processes polling. Anyway this will require some more engineering work, 7.1 is not realistic for it.

Hi Jaroslav,

Thanks!  I'm going to play around with this.

About comment #6, newly created processes.  I can say that the polling method will not be accepted (by customers); especially in the context of MRG, but also RHEL as well.

If I remember correctly, Clark had some ideas in this area, but I don't exactly recall what the were.

If a user adds their own tuned profile that uses this plugin, and puts their application thread regexs in there...the problem is that tuned starts before their app, and thus tuned will not see any matching threads to apply any of the tunings, is that correct ?

(In reply to Jeremy Eder from comment #7)
> If a user adds their own tuned profile that uses this plugin, and puts their
> application thread regexs in there...the problem is that tuned starts before
> their app, and thus tuned will not see any matching threads to apply any of
> the tunings, is that correct ?

Yes, this is correct. Currently it works similar to rtctl. For tuned to apply tunings for customers user space apps, they would need to restart tuned or switch profile.

Feel free to forward me any ideas/proposals regarding tracing of new processes. I would like to select most suitable / universal approach for the implementation.

(In reply to Jaroslav Škarvada from comment #6)
> Regarding tuning of newly created processes I need to think a bit about it.
> Systemtap / LD_PRELOAD may bring performance penalty (for loads creating
> many processes - probably not typical loads). Other possibility is to poll
> e.g. each 10 seconds. There is already infrastructure for this that was used
> for dynamic tuning (already disabled in RHEL). This may be improved just to
> only run monitors for processes polling. Anyway this will require some more
> engineering work, 7.1 is not realistic for it.


You may want to look at 'tuna', where we get the perf subsystem to send us a thread creation event. Tuna used to poll /proc for new threads but we moved to perf where it exists, since it's much lower overhead. 

I'll see if I can find that code and point you at it.

(In reply to Clark Williams from comment #9)
> You may want to look at 'tuna', where we get the perf subsystem to send us a
> thread creation event. Tuna used to poll /proc for new threads but we moved
> to perf where it exists, since it's much lower overhead. 
> 
> I'll see if I can find that code and point you at it.

OK, thanks, NP, I know perf and I saw this code in tuna. So for now this is candidate no. 1.

Closing this for 7.1 and cloning as RFE to 7.2 for runtime detection of processes.

(In reply to Jaroslav Škarvada from comment #4)
> CCing mgrepl, tuned now calls chrt and taskset.

Are there SELinux issues?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0550.html