Advice mode

[the9000]

In this mode bpftune should analyze the activity as normal, and generate desired actions as normal.

But instead of applying the actions immediately, it should suggest the action in a human-readable way, explaining the reasoning behind it, and listing the OS commands necessary to implement them.

The action can then be reviewed and applied, as is, modified, or not at all, by the actual system operator.

The suggested actions should be sent to syslog under a separate topic, a log file, etc, using the normal logging mechanisms already present in bpftune.

Ideally every advice would have a unique identifier, so as to detect duplicate advice, ignore known advice which is not being implemented, etc. The identifier could be e.g. a hash of a canonical representation of the actions to take.

[DominoTree]

This could be incredibly useful to simply find tuneables even worth looking at on systems with existing workloads

[alan-maguire]

see rollback mode, described in issue #19 and merged in #60 . You can basically just run bpftune on the commandline using the -R option, and changes made will be rolled back, but described prior to rollback. As a recap I'll try and describe the approach taken there.

Central to the design of bpftune is that we make changes, see the effects and potentially roll back on those changes or double down on them if they work. Under this model there's no way to not apply suggested changes since the application of changes is needed to assess the effectiveness of the change. As a result, the rollback mode was introduced which tries to find optimal settings and when the program exits it will describe changes made. The changes are rolled back so the admin can decide whether to apply them or not.

[westurner]

From https://news.ycombinator.com/item?id=42163597#42164688 and https://news.ycombinator.com/item?id=42167417 :

usage, main()

• bpftune/src/bpftune.c

  Lines 280 to 296 in 6a50f5f

  	int main(int argc, char *argv[])
  	{
  	static const struct option options[] = {
  	{ "allow", required_argument, NULL, 'a' },
  	{ "cgroup", required_argument, NULL, 'c' },
  	{ "daemon", no_argument, NULL, 'D' },
  	{ "debug", no_argument, NULL, 'd' },
  	{ "legacy", no_argument, NULL, 'L' },
  	{ "help", no_argument, NULL, 'h' },
  	{ "libdir", required_argument, NULL, 'l' },
  	{ "learning_rate", required_argument, NULL, 'r' },
  	{ "rollback", no_argument, NULL, 'R' },
  	{ "stderr", no_argument, NULL, 's' },
  	{ "support", no_argument, NULL, 'S' },
  	{ "version", no_argument, NULL, 'V' },
  	{ 0 }
  	};

• bpftune/src/bpftune.c

  Lines 230 to 244 in 6a50f5f

  	fprintf(stderr,
  	"Usage: %s [OPTIONS]\n"
  	" OPTIONS := { { -a|--allow tuner}\n"
  	" { -d|--debug} {-D|--daemon}\n"
  	" { -c|--cgroup_path cgroup_path}\n"
  	" { -L|--legacy}\n"
  	" { -h|--help}}\n"
  	" { -l|--library_path library_path}\n"
  	" { -r|--learning_rate learning_rate}\n"
  	" { -R|--rollback}\n"
  	" { -s|--stderr}\n"
  	" { -S|--suppport}\n"
  	" { -V|--version}}\n",
  	bin_name);
  	}

.

• DOC: what -R/--rollback does
• ENH: CLI opts: --pretend-allow or --log-only-allow or [...]

Probably relevant function headers in libbpftune.c:

bpftune_sysctl_write(

bpftuner_tunable_sysctl_write(

bpftune_module_load(

static void bpftuner_scenario_log(struct bpftuner *tuner, unsigned int tunable,

• bpftune/src/libbpftune.c

  Line 907 in 6a50f5f

  int bpftune_sysctl_write(int netns_fd, const char *name, __u8 num_values, long *values)

• bpftune/src/libbpftune.c

  Line 1107 in 6a50f5f

  int bpftuner_tunable_sysctl_write(struct bpftuner *tuner, unsigned int tunable,

• bpftune/src/libbpftune.c

  Line 1533 in 6a50f5f

  int bpftune_module_load(const char *name)

• bpftune/src/libbpftune.c

  Line 1047 in 6a50f5f

  static void bpftuner_scenario_log(struct bpftuner *tuner, unsigned int tunable,

  • bpftune/src/libbpftune.c

    Line 716 in 6a50f5f

    static void bpftuner_scenario_log(struct bpftuner *tuner, unsigned int tunable,

[wolfspyre]

concur with a lot of this...
additionally, it might be useful to have a config file like /etc/default/bpftune (or something) that tuning flags can be added to as opposed to adjusting the systemd initscript that gets clobbered on every make install... (or being noisier about the expected way to apply changes to the current config)

Should bpftune's reach extend to ethtool / nic config?

What about IPTables ruleset adjustments?

or Blockdev / IO tuning?

IDK where the juice / squeeze value tradeoff lies .... and where this becomes an utter bikeshed...
regardless, I really appreciate this tool as it is now, and want to see it help more peeps grok low-level tuning... as wow is it complex.

[westurner]

/etc/bpftune.d/ would avoid the need to dpkg-divert or similar to avoid clobbering config; /etc/bpftune.d/10-defaults.conf # pkg1 /etc/bpftune.d/50-localpolicy.conf # pkg2 From https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html :

Do not use diversions for files that have their own native override

mechanisms, such as systemd unit files. From `man systemd.unit` > "System Unit Search Path" https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#System%20Unit%20Search%20Path : /etc/systemd/ [...] /run/systemd/ [...] … /usr/local/lib/systemd/system/* /usr/lib/systemd/system

…

On Mon, Jan 13, 2025, 6:28 PM Wolf Noble ***@***.***> wrote: concur with a lot of this... additionally, it might be useful to have a config file like /etc/default/bpftune (or something) that tuning flags can be added to as opposed to adjusting the systemd initscript that gets clobbered on every make install... (or being noisier about the expected way to apply changes to the current config) Should bpftune's reach extend to ethtool / nic config? What about IPTables ruleset adjustments? or Blockdev / IO tuning? IDK where the juice / squeeze value tradeoff lies .... and where this becomes an utter bikeshed... regardless, I really appreciate this tool as it is now, and want to see it help more peeps grok low-level tuning... as wow is it complex. — Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMNS2EPWJF3U6EROFRSP32KRD3TAVCNFSM6AAAAABR6BY3WGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBYGQ2TGNBQGM> . You are receiving this because you commented.Message ID: ***@***.***>