suse / phoebe Goto Github PK

I believe this project can gain more traction if we can showcase the project to a wider audience that adding artificial intelligence capabilities to Linux OS works, i.e. auto-tuning does indeed yield better performance. (I'm leaving out the self-healing part for now, as it seems harder than auto-tuning).

What I mean by wider audience is for someone with little knowledge of system and artificial intelligence to be able setup a scenario (or a benchmark), run the project and easily observe that the performance improved when auto-tuning is in action (ideally with all that done by a single script). To achieve that, there are still quite some challenges ahead.

First off, the scenario should be easy to setup. Right now we use TREX in our target scenario, which is not the easiest to setup; while its performance is superior, it support much less network interface cards compared to the Linux kernel. This is easily solvable to switching to other packet generators (e.g. iperf3, sockperf, ab, etc.), and is a minor issue compared to the next one.

Now, addressing the elephant in the room.

The core of Phoeβe lies in its brain, the decision making engine that will take system telemetry as input, and output a set of system-level parameters that improves the system's performance when applied.

But so far we have not been able to prove that this most curcial piece of the project works, that is, show that it can output system settings that does improve the system's performance. This is our second (albeit the major) issue we have that prevented us from showcasing the project to a wider audience.

I hope this proposal make sense, and if so, perhaps we can proceed to a discussion on how can we improve the decision engine (more data points for csv_files/rates.csv? collect more metric for the decision engine?) and have a simpler setup.

I am trying to build using meson as given in readme. But after I execute third line it gives error

Please see if it same for others .

The collect_stats.py script tries to query the current cpu frequency and governor from sysfs:

Unfortunately, this fails in the github actions with:

Traceback (most recent call last):
  File "/__w/phoebe/phoebe/scripts/collect_stats.py", line 306, in <module>
    main(sys.argv[1], settings, count)
  File "/__w/phoebe/phoebe/scripts/collect_stats.py", line 271, in main
    collect_stats(
  File "/__w/phoebe/phoebe/scripts/collect_stats.py", line 187, in collect_stats
    with open(SYSFS_CPU_PATH + 'cpu0/cpufreq/scaling_governor') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor'

I suspect that this is caused by the github actions runner not allowing the CI action to query these information to prevent it from modifying the CPU behavior.

@shunghsiyu I was told you introduced this, can we remove it for the meantime?

1. scripts - folder copied empty.
   Expected : needs to contain python script
2. attempt to run scripts/collect_stats.py end up with Module not found "_phobe"
   Expected: meson script suppose to install need python module

I tried setting up phoebe on a new Tumbleweed VM today and I had a couple of issues with missing dependencies:

1. libnl-3.0 was missing
2. json-c was missing
3. I had a couple of issues with cmocka. After building from source, I tried building phoebe and ran into linker issues. Installing RPMs from rpmfind fixed the issue. Could somebody confirm if this is the expected way to fulfil the cmocka dependency, I haven't used it before and I was wondering if I was missing something in the process?

It'd be great to have a bit more detailed instructions for building the repository. I could create an INSTALL.md file to add more instructions to build on Tumbleweed to begin with