lisa issueshttps://gitlab.arm.com/tooling/lisa/-/issues2024-02-09T12:42:42Zhttps://gitlab.arm.com/tooling/lisa/-/issues/434Calculating residencies more flexibly on a trace2024-02-09T12:42:42ZDarryl GreenCalculating residencies more flexibly on a trace*Created by: joelagnel*
Definition of residency (my definition): The total amount of run time or percentage of time a given PID runs on an entity (entities can be core, cluster, cgroup). In such calculations the idle time isn't accounte...*Created by: joelagnel*
Definition of residency (my definition): The total amount of run time or percentage of time a given PID runs on an entity (entities can be core, cluster, cgroup). In such calculations the idle time isn't accounted.
It would be nice to add an API to calculate residencies per-PID, per-TGID and per-CGroup globally. For Android especially this is helpful to do because it gives better understanding per-usecase of which CPUs time is spent on.
For example -
* For camera startup use case, we want Camera app's UiThread to be placed more on big cluster
* Processes in top-app and foreground CGroup should generally run more often on the big cluster
* For a background workload like System server's background thread, we want it to run most of the time on little cluster
It would helpful to auto analyze everything in the trace and present to the user statistics than manually select threads and do an analysis. Such analysis would be useful to be grouped per-TGID since several PID share the same name and its confusing for analysis when looking at individually PIDs. Its more useful to start from the TGID-level (like YouTube app) and then drill down from there.
Discussed with @derkling @sinkap and the callbacks API can be used here to speed things up, lets develop something along these lines. Either we can improve BART with callbacks API and call that from LISA or push new API to LISA based on the callbacks. I like the BART approach because the logic for "grouping" residency based on cluster level is already done there.
If going through LISA-only approach, I was thinking we add a new `ResidencyAnalysis` class to `libs/utils/analysis` to LISA which is flexible to cover different cases.
Lets chat what's the best design approach here to move forward, thanks.https://gitlab.arm.com/tooling/lisa/-/issues/1838Can lisa analyze systrace.html or perfetto?2024-02-09T12:42:34ZDarryl GreenCan lisa analyze systrace.html or perfetto?*Created by: accsky*
IN https://lisa-linux-integrated-system-analysis.readthedocs.io/en/master/trace_analysis.html#trace :
![image](https://user-images.githubusercontent.com/51768765/169506389-f4a8d2bd-c4ac-4896-a543-386cda9d1501.png)
I...*Created by: accsky*
IN https://lisa-linux-integrated-system-analysis.readthedocs.io/en/master/trace_analysis.html#trace :
![image](https://user-images.githubusercontent.com/51768765/169506389-f4a8d2bd-c4ac-4896-a543-386cda9d1501.png)
I would like to ask is it effective to analyze systrace with lisa? Because we generally capture systrace or Perfetto offline.https://gitlab.arm.com/tooling/lisa/-/issues/248Set up ADB USB udev permissions in Vagrantfile2024-02-09T12:42:32ZDarryl GreenSet up ADB USB udev permissions in Vagrantfile*Created by: bjackman*
We should automatically add a [udev rules file](https://wiki.cyanogenmod.org/w/UDEV) in Vagrant VMs so that the vagrant user has permissions to access ADB devices.*Created by: bjackman*
We should automatically add a [udev rules file](https://wiki.cyanogenmod.org/w/UDEV) in Vagrant VMs so that the vagrant user has permissions to access ADB devices.https://gitlab.arm.com/tooling/lisa/-/issues/84Results processor for LISA2024-02-09T12:42:29ZDarryl GreenResults processor for LISA*Created by: raw-bin*
[Disclaimer: The enhancements here may not be applicable to LISA alone but I'll mention them here all the same to gather viewpoints. I've also not been through all the issues in the issue list - so there may be som...*Created by: raw-bin*
[Disclaimer: The enhancements here may not be applicable to LISA alone but I'll mention them here all the same to gather viewpoints. I've also not been through all the issues in the issue list - so there may be some redundancy].
There's a set of common 'views' of data that can be very useful in diagnosing a given use-case or system to form a first order viewpoint for diagnosis etc.
For example - in the past cr2 produced a fixed set of plots that were very valuable to form an initial opinion of what's up. It would be good to have a similar setup with one 'report' generator that first confirms that all necessary tokens are available in input trace and if so, produces all the views.
It's kind of easy to get carried away with this sort of stuff admittedly - one type of view can sometimes be inferred from another so you don't always want to plot every type of view. However, in my experience, if the generation cost is minimal, having multiple views of interest - some redundancy notwithstanding - is a very useful correlation tool to diagnose problems.
Some of the views that I can think of are:
1. OPP residency break-down for a given trace input.
- Per-CPU OPP residency break-down in a suitable plot.
- Great to know where the compute's going. For example, Audio playback should show low OPPs on the LITTLE side only etc.
- @JaviMerino has an implementation internally which might be reusable.
2. Idle state residency break-down.
- Per-CPU/cluster idle residency break-down in a suitable plot.
- Similar to 1 above, can help correlate problems.
3. Parallelisation scoring for a given trace input.
- Aggregate scoring - ie what %age of time were N cpus active (N: {0,1,...NCPUs}) - in a suitable plot.
- Most obvious use is for benchmarks where you want to verify for example 1 thread per CPU kind of dynamic.
- WA has a [result processor](https://github.com/ARM-software/workload-automation/blob/master/wlauto/result_processors/cpustate.py) that does this and the above. IMHO those kind of processors are better implemented in LISA.
4. IRQ histogram by CPU
- Great for confirming who's causing frequent wake-ups on the wrong CPU type for example.
Some more items that came up in recent discussions which are worth including in a 'top level diagnostic notebook':
1. Per CPU task context switch count
- Could help in contrast analyses for a given use-case between EAS and other strategies (including default mainline behaviour)
2. OPP transition rate indication
- The idea being that you can see if scheduler driven DVFS is being too trigger happy compared to conventional governors
Please add to the list as ideas come up.https://gitlab.arm.com/tooling/lisa/-/issues/2174kmodules building failed2024-01-18T11:06:52ZDarryl Greenkmodules building failed*Created by: Jiaming97*
**Describe the bug**
I met with the bug when I tried to build kmodules using alpine.
**To Reproduce**
The version of the LISA is v3.1.0.
I have followed the LISA guide to create the `target_conf.yml`. [E...*Created by: Jiaming97*
**Describe the bug**
I met with the bug when I tried to build kmodules using alpine.
**To Reproduce**
The version of the LISA is v3.1.0.
I have followed the LISA guide to create the `target_conf.yml`. [Enabling a module](https://lisa-linux-integrated-system-analysis.readthedocs.io/en/v3.1.0/setup.html#enabling-a-module)
Here is my `target_conf.yml`. The environment of the target is buildroot.
```
target-conf:
kind: linux
name: tc
host: localhost
port: 8023
username: root
password: ""
strict-host-check: false
kernel:
src: /home/jiaguo01/workzone/TC2/buildroot/output/buildroot/tmp_build/linux
modules:
make-variables:
CC: clang
LLVM: -16
build-env: alpine
wait-boot:
enable: false
devlib:
file-xfer: scp
max-async: 1
```
When I tried to build and load the kmodules. The error log is as follows.
```
[LISAShell lisa] \> lisa-load-kmod --conf target_conf.yml -- echo hello world
[2024-01-17 16:10:05,597][lisa.target.Target] INFO Target configuration:
+- devlib:
|- excluded-modules from target_conf.yml (list): []
|- file-xfer from target_conf.yml (str): scp
|- max-async from target_conf.yml (int): 1
+- platform:
|- class from target_conf.yml (str): devlib.platform.Platform
|- host from target_conf.yml (str): localhost
+- kernel:
+- modules:
|- build-env from target_conf.yml (str): alpine
|- make-variables from target_conf.yml (dict): {'CC': 'clang', 'LLVM': -16}
|- src from target_conf.yml (str): /home/jiaguo01/workzone/TC2/buildroot/output/buildroot/tmp_build/linux
|- kind from target_conf.yml (str): linux
|- lazy-platinfo from target_conf.yml (bool): False
|- name from target_conf.yml (str): tc
|- password from target_conf.yml (str): <password>
|- port from target_conf.yml (int): 8023
|- strict-host-check from target_conf.yml (bool): False
|- tools from target_conf.yml (list): []
|- username from target_conf.yml (str): root
+- wait-boot:
|- enable from target_conf.yml (bool): False
|- timeout from target_conf.yml (int): 10
[2024-01-17 16:10:05,598][lisa.target.Target] INFO Creating result directory: /workzone/jiaguo01/LISA/lisa/results/Target-tc-20240117_161005.598085
[2024-01-17 16:10:28,367][lisa.target.Target] INFO Connected to target tc
[2024-01-17 16:10:29,292][lisa.energy_model.EnergyModel.from_target] INFO Attempting to load EM using LinuxEnergyModel
[2024-01-17 16:10:37,811][lisa.target.Target] INFO Loading target devlib module cpuidle
[2024-01-17 16:10:47,174][lisa.target.Target] INFO Loading target devlib module cpufreq
[2024-01-17 16:10:53,988][lisa.target.Target] INFO Loading target devlib module sched
[2024-01-17 16:11:00,920][sched] INFO Scheduler sched_domain procfs entries found
[2024-01-17 16:11:00,920][sched] INFO Detected kernel compiled with SCHED_DEBUG=y
[2024-01-17 16:11:00,920][sched] INFO CPU capacity sysfs entries found
[2024-01-17 16:11:11,402][lisa.target.Target] INFO Effective platform information:
|- abi from target (str): arm64
+- cpu-capacities:
|- orig from target (dict): {0: 286, 1: 286, 2: 286, 3: 286, 4: 793, 5: 793, 6: 793, 7: 1024}
|- writeable from target (bool): False
|- rtapp from target(platform-info/rtapp/calib),target(platform-info/cpu-capacities/orig),target(platform-info/cpu-capacities/writeable) (str): <depends on lazy keys: platform-info/rtapp/calib>
|- cpus-count from target (int): 8
|- freq-domains from target (list): [[0, 1, 2, 3], [4, 5, 6], [7]]
|- freqs from target (dict): {0: [768000, 1153000, 1537000, 1844000, 2152000], 1: [768000, 1153000, 1537000, 1844000, 2152000], 2: [768000, 1153000, 1537000, 1844000, 2152000], 3: [768000, 1153000, 1537000, 1844000, 2152000], 4: [946000, 1419000, 1893000, 2271000, 2650000], 5: [946000, 1419000, 1893000, 2271000, 2650000], 6: [946000, 1419000, 1893000, 2271000, 2650000], 7: [1088000, 1632000, 2176000, 2612000, 3047000]}
+- kernel:
|- config from target (TypedKernelConfig): <kernel config>
|- symbols-address from target (DeferredValue): <symbols address>
|- version from target (KernelVersion): 5.15.41-g7385306ee901-dirty 1 SMP PREEMPT Wed Jan 17 14:26:11 CST 2024
|- name from target-conf (str): tc
|- nrg-model from target (LinuxEnergyModel): <lisa.energy_model.LinuxEnergyModel object at 0x7fdc90b6e370>
|- numa-nodes-count from target (int): 1
|- os from target (str): linux
+- rtapp:
|- calib from target (DeferredValue): <lazy value of RTA.get_cpu_calibrations>
|- capacity-classes from target(platform-info/cpu-capacities/orig) (list): [[0, 1, 2, 3], [4, 5, 6], [7]]
[2024-01-17 16:11:11,402][lisa._kmod.KernelTree] INFO Detected CROSS_COMPILE=aarch64-linux-gnu- and CC=clang
[2024-01-17 16:11:55,882][lisa._kmod.KernelTree] INFO Detected CROSS_COMPILE=aarch64-linux-gnu- and CC=clang
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
[2024-01-17 16:11:55,907][lisa._kmod.alpine_chroot] INFO Setting up Alpine chroot from https://dl-cdn.alpinelinux.org/alpine/v3.17/releases/x86_64/alpine-minirootfs-3.17.3-x86_64.tar.gz -> /workzone/jiaguo01/LISA/lisa/cache/git-5315fabab791fa313e9007c31c3777c7b7d2dce8-dirty-d03c28ea4c554840c813073a22a39c1020119305/alpine_chroot/tmp4m8o48ww/tmphqssvyyp
[2024-01-17 16:12:08,154][lisa._kmod.KernelTree] INFO Preparing kernel tree for modules
[2024-01-17 16:12:08,218][lisa._kmod.KernelTree] INFO Detected CROSS_COMPILE=aarch64-linux-gnu- and CC=clang
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
[2024-01-17 16:12:08,250][lisa._kmod.KernelTree] INFO Preparing kernel tree for modules
[2024-01-17 16:12:08,302][lisa._kmod.KernelTree] INFO Detected CROSS_COMPILE=aarch64-linux-gnu- and CC=clang
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
[2024-01-17 16:12:08,340][lisa._kmod.KernelTree] INFO Preparing kernel tree for modules
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1866, in _do_compile
key = get_key(kernel_tree)
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1828, in get_key
raise ValueError('Kernel tree has no checksum')
ValueError: Kernel tree has no checksum
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "/workzone/jiaguo01/LISA/lisa/lisa/_unshare.py", line 110, in _unshare_wrapper
return f(*args, **kwargs)
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1868, in _do_compile
with kernel_tree as kernel_tree:
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 714, in __enter__
spec = cm.__enter__()
File "/usr/lib/python3.8/contextlib.py", line 113, in __enter__
return next(self.gen)
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1305, in try_loaders
raise ValueError(f'Could not load kernel trees:\n{excep_str}')
ValueError: Could not load kernel trees:
from_installed_headers: ValueError: Building from /lib/modules is not supported with the Alpine build environment as /lib/modules might not be self contained (i.e. symlinks pointing outside)
from_sysfs_headers: CalledProcessError: Command '['chroot', PosixPath('/tmp/tmpla06phsw/overlaid'), 'sh', '-c', 'source /etc/profile && exec make -j36 -C /tmp/tmpxup6g0gx/overlaid -- ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- KBUILD_MODPOST_WARN=1 LLVM=1 mrproper']' returned non-zero exit status 2.:
make: Entering directory '/tmp/tmpxup6g0gx/overlaid'
Makefile:2: /workzone/jiaguo01/TC2/buildroot/src/linux/Makefile: No such file or directory
make: *** No rule to make target '/workzone/jiaguo01/TC2/buildroot/src/linux/Makefile'. Stop.
make: Leaving directory '/tmp/tmpxup6g0gx/overlaid'
from_proc_config: CalledProcessError: Command '['chroot', PosixPath('/tmp/tmpz32klin8/overlaid'), 'sh', '-c', 'source /etc/profile && exec make -j36 -C /tmp/tmpf2gx9rhu/overlaid -- ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- KBUILD_MODPOST_WARN=1 LLVM=1 mrproper']' returned non-zero exit status 2.:
make: Entering directory '/tmp/tmpf2gx9rhu/overlaid'
Makefile:2: /workzone/jiaguo01/TC2/buildroot/src/linux/Makefile: No such file or directory
make: *** No rule to make target '/workzone/jiaguo01/TC2/buildroot/src/linux/Makefile'. Stop.
make: Leaving directory '/tmp/tmpf2gx9rhu/overlaid'
from_user_tree: CalledProcessError: Command '['chroot', PosixPath('/tmp/tmpadj20lo8/overlaid'), 'sh', '-c', 'source /etc/profile && exec make -j36 -C /tmp/tmpse8x466y/overlaid -- ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- KBUILD_MODPOST_WARN=1 LLVM=1 mrproper']' returned non-zero exit status 2.:
make: Entering directory '/tmp/tmpse8x466y/overlaid'
Makefile:2: /workzone/jiaguo01/TC2/buildroot/src/linux/Makefile: No such file or directory
make: *** No rule to make target '/workzone/jiaguo01/TC2/buildroot/src/linux/Makefile'. Stop.
make: Leaving directory '/tmp/tmpse8x466y/overlaid'
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/workzone/jiaguo01/LISA/lisa/.lisa-venv-3.8/bin/lisa-load-kmod", line 33, in <module>
sys.exit(load_entry_point('lisa-linux', 'console_scripts', 'lisa-load-kmod')())
File "/workzone/jiaguo01/LISA/lisa/lisa/_cli_tools/lisa_load_kmod.py", line 111, in main
with dmesg_cm(), kmod_cm:
File "/usr/lib/python3.8/contextlib.py", line 113, in __enter__
return next(self.gen)
File "/workzone/jiaguo01/LISA/lisa/lisa/_cli_tools/lisa_load_kmod.py", line 69, in cm
with _kmod_cm:
File "/workzone/jiaguo01/LISA/lisa/lisa/utils.py", line 2840, in __enter__
return cm.__enter__()
File "/usr/lib/python3.8/contextlib.py", line 113, in __enter__
return next(self.gen)
File "/workzone/jiaguo01/LISA/lisa/lisa/utils.py", line 2806, in _wrap_gen
res = gen.send(None)
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1946, in run
x = self.install(**kwargs)
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1966, in install
return super().install(*args, **kwargs)
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1906, in install
content = self._compile()
File "/workzone/jiaguo01/LISA/lisa/lisa/utils.py", line 586, in wrapper
raise e
File "/workzone/jiaguo01/LISA/lisa/lisa/utils.py", line 572, in catch
x = f(*args, **kwargs)
File "/workzone/jiaguo01/LISA/lisa/lisa/_kmod.py", line 1812, in _compile
bin_, spec = compile_(self)
File "/workzone/jiaguo01/LISA/lisa/lisa/_unshare.py", line 223, in wrapper
return _with_unshare(f, args=args, kwargs=kwargs)
File "/workzone/jiaguo01/LISA/lisa/lisa/_unshare.py", line 194, in _with_unshare
return pool.apply(
File "/usr/lib/python3.8/multiprocessing/pool.py", line 357, in apply
return self.apply_async(func, args, kwds).get()
File "/usr/lib/python3.8/multiprocessing/pool.py", line 771, in get
raise self._value
ValueError: Could not load kernel trees:
**from_installed_headers: ValueError: Building from /lib/modules is not supported with the Alpine build environment as /lib/modules might not be self contained (i.e. symlinks pointing outside)**
from_sysfs_headers: CalledProcessError: Command '['chroot', PosixPath('/tmp/tmpla06phsw/overlaid'), 'sh', '-c', 'source /etc/profile && exec make -j36 -C /tmp/tmpxup6g0gx/overlaid -- ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- KBUILD_MODPOST_WARN=1 LLVM=1 mrproper']' returned non-zero exit status 2.:
make: Entering directory '/tmp/tmpxup6g0gx/overlaid'
Makefile:2: /workzone/jiaguo01/TC2/buildroot/src/linux/Makefile: No such file or directory
**make: *** No rule to make target '/workzone/jiaguo01/TC2/buildroot/src/linux/Makefile'. Stop.**
make: Leaving directory '/tmp/tmpxup6g0gx/overlaid'
from_proc_config: CalledProcessError: Command '['chroot', PosixPath('/tmp/tmpz32klin8/overlaid'), 'sh', '-c', 'source /etc/profile && exec make -j36 -C /tmp/tmpf2gx9rhu/overlaid -- ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- KBUILD_MODPOST_WARN=1 LLVM=1 mrproper']' returned non-zero exit status 2.:
make: Entering directory '/tmp/tmpf2gx9rhu/overlaid'
Makefile:2: /workzone/jiaguo01/TC2/buildroot/src/linux/Makefile: No such file or directory
make: *** No rule to make target '/workzone/jiaguo01/TC2/buildroot/src/linux/Makefile'. Stop.
make: Leaving directory '/tmp/tmpf2gx9rhu/overlaid'
from_user_tree: CalledProcessError: Command '['chroot', PosixPath('/tmp/tmpadj20lo8/overlaid'), 'sh', '-c', 'source /etc/profile && exec make -j36 -C /tmp/tmpse8x466y/overlaid -- ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- KBUILD_MODPOST_WARN=1 LLVM=1 mrproper']' returned non-zero exit status 2.:
make: Entering directory '/tmp/tmpse8x466y/overlaid'
Makefile:2: /workzone/jiaguo01/TC2/buildroot/src/linux/Makefile: No such file or directory
make: *** No rule to make target '/workzone/jiaguo01/TC2/buildroot/src/linux/Makefile'. Stop.
make: Leaving directory '/tmp/tmpse8x466y/overlaid'
```
I have checked the path, the file `/workzone/jiaguo01/TC2/buildroot/src/linux/Makefile` exists.
Acutally, when I tried to build without the following settings in the `target_conf.yml`. The modules can be built successfully.
```
modules:
make-variables:
CC: clang
LLVM: -16
build-env: alpine
```
So, I think the problem may due to the alpine. Could you please check with it? Thanks!https://gitlab.arm.com/tooling/lisa/-/issues/1948When I run lisa-test. "Command '<Workload RTA>' returned non-zero exit status...2024-01-16T16:44:04ZDarryl GreenWhen I run lisa-test. "Command '<Workload RTA>' returned non-zero exit status 2 "Wrong, how can I solve this?*Created by: wuhao-1998*
When I run lisa-test. "Command '<Workload RTA>' returned non-zero exit status 2 "Wrong, how can I solve this?
EnergyModelWakeMigration:test_dmesg
EnergyModelWakeMigration:test_slack
EnergyModelWakeMigra...*Created by: wuhao-1998*
When I run lisa-test. "Command '<Workload RTA>' returned non-zero exit status 2 "Wrong, how can I solve this?
EnergyModelWakeMigration:test_dmesg
EnergyModelWakeMigration:test_slack
EnergyModelWakeMigration:test_task_placement
。。。。。。。。。。。。
https://gitlab.arm.com/tooling/lisa/-/issues/2144cpu_capacity_orig goes away in kernel after Patch2023-12-22T13:26:17ZDarryl Greencpu_capacity_orig goes away in kernel after Patch*Created by: credp*
In https://lore.kernel.org/all/20231009103621.374412-2-vincent.guittot@linaro.org/
the cpu_capacity_orig field is removed. This is related to the current issue of the load-tracking test not working.
https://gith...*Created by: credp*
In https://lore.kernel.org/all/20231009103621.374412-2-vincent.guittot@linaro.org/
the cpu_capacity_orig field is removed. This is related to the current issue of the load-tracking test not working.
https://github.com/ARM-software/lisa/blob/627de71146862d516b62d8eef7ec89f740e40329/lisa/_assets/kmodules/lisa/sched_helpers.h#L217https://gitlab.arm.com/tooling/lisa/-/issues/2114TypeError caused by PeriodicWload.unscaled_duty_cycle_pct2023-09-20T13:21:39ZDarryl GreenTypeError caused by PeriodicWload.unscaled_duty_cycle_pct*Created by: chrisswinchatt-arm*
Apologies for deviating from the standard bug report format, but I don't think it's necessary as the bug is straightforward. This bug is present at HEAD (at time of writing).
`PeriodicWload.unscaled_d...*Created by: chrisswinchatt-arm*
Apologies for deviating from the standard bug report format, but I don't think it's necessary as the bug is straightforward. This bug is present at HEAD (at time of writing).
`PeriodicWload.unscaled_duty_cycle_pct` passes a list to `MultiSrcConf.get_key` which tries to use the list as a key and triggers the `TypeError`.
The stack trace is pretty illustrative of what the problem is:
```python
File ~/Work/experiments/lisa/lisa/wlgen/rta.py:2994, in PeriodicWload.unscaled_duty_cycle_pct(self, plat_info)
2991 capa = plat_info.get_nested_key(['cpu-capacities', 'rtapp'], quiet=True)[cpu]
2993 if freq is not None:
-> 2994 freqs = plat_info.get_key(['freqs'], quiet=True)[cpu]
2995 capa *= freq / max(freqs)
2997 capa /= PELT_SCALE
File ~/Work/experiments/lisa/lisa/conf.py:1769, in MultiSrcConf.get_key(self, key, src, eval_deferred, quiet)
1766 if key == '..':
1767 return self._parent
-> 1769 key_desc = self._structure[key]
1771 if isinstance(key_desc, LevelKeyDesc):
1772 return self._sublevel_map[key]
File ~/Work/experiments/lisa/lisa/conf.py:632, in LevelKeyDesc.__getitem__(self, key)
631 def __getitem__(self, key):
--> 632 self.check_allowed_key(key)
633 return self._key_map[key]
File ~/Work/experiments/lisa/lisa/conf.py:640, in LevelKeyDesc.check_allowed_key(self, key)
636 """
637 Checks that a given key is allowed under that levels
638 """
639 try:
--> 640 self._key_map[key]
641 except KeyError:
642 # pylint: disable=raise-missing-from
643 try:
TypeError: unhashable type: 'list'
```
As you can see, `PeriodicWload.unscaled_duty_cycle_pct` passes a list of key names to `MultiSrcConf.get_key` which then calls `LevelKeyDesc.__getitem__` which calls `LevelKeyDesc.check_allowed_key` which tries to use the list as a key into `self._key_map`, thus triggering the `TypeError`. The fix is presumably to change the list containing one string to just a string.https://gitlab.arm.com/tooling/lisa/-/issues/1914How to control the capture time of trace.dat?2022-12-04T05:30:48ZDarryl GreenHow to control the capture time of trace.dat?*Created by: wuhao-1998*
Hello, How is the duration of the trace.dat controlled? By file size? Or time?
I don't seem to notice the configuration when I have time. I studied lisa/trace.py 和 lisa/target.py are not found.
And through ma...*Created by: wuhao-1998*
Hello, How is the duration of the trace.dat controlled? By file size? Or time?
I don't seem to notice the configuration when I have time. I studied lisa/trace.py 和 lisa/target.py are not found.
And through many experiments, the trace time is 1-2s, and the size is between 30MB and 45MB, which is not fixed. How can I extend trace.dat?https://gitlab.arm.com/tooling/lisa/-/issues/1906The running time of a task at each frequency on each CPU 2022-11-18T11:59:44ZDarryl GreenThe running time of a task at each frequency on each CPU *Created by: wuhao-1998*
How to calculate the running time of a task at each frequency on each CPU to form a dataframe?
This is an excel sheet I made with lisa, but it is missing a usage rate for each frequency, can you help me? Or can...*Created by: wuhao-1998*
How to calculate the running time of a task at each frequency on each CPU to form a dataframe?
This is an excel sheet I made with lisa, but it is missing a usage rate for each frequency, can you help me? Or can you give me some hints?
![image](https://user-images.githubusercontent.com/67492545/199971479-ac5cecd1-d783-4056-bfad-00c2150f7498.png)
https://gitlab.arm.com/tooling/lisa/-/issues/1902How to use Lisa to obtain cpu usage and generate a chart2022-11-18T11:59:17ZDarryl GreenHow to use Lisa to obtain cpu usage and generate a chart*Created by: wuhao-1998*
Can you give me some ideas? Thank you
![image](https://user-images.githubusercontent.com/67492545/196018283-a9e208da-bc24-4615-a830-cc279036d9c8.png)
*Created by: wuhao-1998*
Can you give me some ideas? Thank you
![image](https://user-images.githubusercontent.com/67492545/196018283-a9e208da-bc24-4615-a830-cc279036d9c8.png)
https://gitlab.arm.com/tooling/lisa/-/issues/1842running `df_all_events` without executing `trace-cmd` separately for each event2022-10-14T11:43:13ZDarryl Greenrunning `df_all_events` without executing `trace-cmd` separately for each event*Created by: Avidanborisov*
I'm trying to use lisa to conveniently parse all the events from a trace.dat file into a DataFrame, with additional columns from the event arguments (such as `func` from `funcgraph_entry`/`funcgraph_exit`) to...*Created by: Avidanborisov*
I'm trying to use lisa to conveniently parse all the events from a trace.dat file into a DataFrame, with additional columns from the event arguments (such as `func` from `funcgraph_entry`/`funcgraph_exit`) to appear on the DataFrame. Here's an example -
```
import lisa.trace.Trace
t = lisa.trace.Trace("trace.dat")
df = t.df_all_events(fields_as_cols=["__cpu", "__comm", "__pid", "func"])
```
Running this on a trace.dat file with ~2 million events and ~14 different kinds of events takes a good few minutes to complete. I've noticed that a separate `trace-cmd` process is getting executed for each event separately (with an `-r event_name` argument), and an additional initial invocation with no events at all.
Is there a way to parse all events together with a single `trace-cmd` invocation, thus reducing time for this to complete?
Thanks!https://gitlab.arm.com/tooling/lisa/-/issues/1900How to capture trace.dat without wload2022-10-14T11:42:23ZDarryl GreenHow to capture trace.dat without wload*Created by: accsky*
How to capture trace.dat only use FtraceCollector?
![image](https://user-images.githubusercontent.com/51768765/195525549-edf0e8bc-9f84-4abf-8421-bda1c97c8023.png)
thanks*Created by: accsky*
How to capture trace.dat only use FtraceCollector?
![image](https://user-images.githubusercontent.com/51768765/195525549-edf0e8bc-9f84-4abf-8421-bda1c97c8023.png)
thankshttps://gitlab.arm.com/tooling/lisa/-/issues/1749Issue: trace.ana.tasks.plot_task_residency() fails to plot for all domains2022-06-22T08:31:14ZDarryl GreenIssue: trace.ana.tasks.plot_task_residency() fails to plot for all domains*Created by: Leo-Yan*
**Describe the bug**
The system have two CPU freq domains, the first domain is CPU0/1/2/3, the second domain is CPU4/5/67/; When use notebook to analyze task behaviour, the method trace.ana.tasks.plot_task_residen...*Created by: Leo-Yan*
**Describe the bug**
The system have two CPU freq domains, the first domain is CPU0/1/2/3, the second domain is CPU4/5/67/; When use notebook to analyze task behaviour, the method trace.ana.tasks.plot_task_residency() only can plot the task residency on the first CPU domain (CPU0/1/2/3), but it doesn't show up the task residency on the second CPU domain.
**To Reproduce**
Steps to reproduce the behavior:
* what part of LISA is being used (synthetic tests, WA-related features, etc.): synthetic tests
* what kind of target is being used (linux, android, etc.): Hikey960 with Android
* what code is being run if that is a custom script using LISA APIs:
Please see the ipython script: https://gist.github.com/Leo-Yan/c1e33b0c399762dcbbe943fc632fbad5; you could see at the box 'In [84]:', it calls method trace.ana.tasks.plot_task_residency("tsk4_1-13"), the picture only show CPUs 0\~3 but have no CPUs 4\~7.
https://gitlab.arm.com/tooling/lisa/-/issues/1846lisa-test reports failure "EXCEPTION (AttributeError): 'DataFrame' object has...2022-06-22T08:29:04ZDarryl Greenlisa-test reports failure "EXCEPTION (AttributeError): 'DataFrame' object has no attribute 'event_name'"*Created by: Leo-Yan*
**Describe the bug**
When I execute the command: lisa-test '*test_task_placement', it reports the failure:
EXCEPTION (AttributeError): 'DataFrame' object has no attribute 'event_name'
**To Reproduce**
Steps t...*Created by: Leo-Yan*
**Describe the bug**
When I execute the command: lisa-test '*test_task_placement', it reports the failure:
EXCEPTION (AttributeError): 'DataFrame' object has no attribute 'event_name'
**To Reproduce**
Steps to reproduce the behavior:
* lisa-test
* Hikey960 with mainline kernel 5.19
* No any other custom change
**Expected behavior/what was the purpose of the experiment**
n/a
**Logs of the error**
```
[2022-06-14 10:28:26,863][lisa.target.Target] WARNING Could not freeze userspace: "cgroups" devlib module is necessary
[2022-06-14 10:28:26,889][lisa.wlgen.rta.RTA] INFO Created workload's run target directory: /root/devlib-target/lisa/wlgen/20220614_102826_592e280c4e184a60abb5c10cd53cfb1e
[2022-06-14 10:28:27,120][lisa.wlgen.rta.RTA] WARNING CPU capacities will not be updated on this platform
[2022-06-14 10:28:27,133][lisa.wlgen.rta.RTA] INFO CPU capacities according to rt-app workload: {0: 462, 1: 462, 2: 462, 3: 462, 4: 1024, 5: 1024, 6: 1024, 7: 1024}
[2022-06-14 10:28:34,451][lisa.wlgen.rta.RTA] INFO Execution start: rt-app /root/devlib-target/lisa/wlgen/20220614_102826_592e280c4e184a60abb5c10cd53cfb1e/rta_energymodelwakemigration.json 2>&1
[2022-06-14 10:29:02,493][lisa.wlgen.rta.RTA] INFO Wiping target run directory: /root/devlib-target/lisa/wlgen/20220614_102826_592e280c4e184a60abb5c10cd53cfb1e
[2022-06-14 10:29:03,369][lisa.target.Target] INFO Re-enabling idle states for all domains
[2022-06-14 10:29:05,342][EXEKALL] INFO Computed EnergyModelWakeMigration.from_target[board=hikey960] UUID=d3056671fb654a62a01055498aee672f
[2022-06-14 10:29:06,931][lisa.platforms.platinfo.PlatformInfo] INFO Attempting to read kallsyms from target
[2022-06-14 10:29:21,192][EXEKALL] INFO Computed EnergyModelWakeMigration.from_target[board=hikey960]:EASBehaviour.test_task_placement UUID=3f5859f6813049e8900548ee470df711
[2022-06-14 10:29:21,194][EXEKALL] ERROR AttributeError: 'DataFrame' object has no attribute 'event_name'
ID: lisa.target.TargetConf:lisa.target.Target.from_conf[board=hikey960](res_dir=lisa.exekall_customize.ExekallArtifactPath.from_expr_data,plat_info=lisa.platforms.platinfo.PlatformInfo):lisa.tests.base.EnergyModelWakeMigration.from_target[board=hikey960](res_dir=lisa.exekall_customize.ExekallArtifactPath.from_expr_data,ftrace_conf=lisa.trace.FtraceConf):lisa.tests.scheduler.eas_behaviour.EASBehaviour.test_task_placement
Traceback (most recent call last):
File "/home/leoy/Work2/tools/lisa/tools/exekall/exekall/engine.py", line 2857, in genf
val = self.callable_(**kwargs)
File "/home/leoy/Work2/tools/lisa/tools/exekall/exekall/engine.py", line 2338, in __call__
return __UnboundMethod_self__.__wrapped__(*args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/tests/base.py", line 492, in wrapper
res = func(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4876, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 2319, in wrapper
return f(**kwargs, **dispatched)
File "/home/leoy/Work2/tools/lisa/lisa/tests/base.py", line 614, in filter_wrapper
res = wrapped_test(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 541, in wrapper
raise e
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 527, in catch
x = f(*args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/tests/scheduler/eas_behaviour.py", line 492, in test_task_placement
exp_power = self._get_expected_power_df(nrg_model, capacity_margin_pct)
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4876, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/tests/scheduler/eas_behaviour.py", line 390, in _get_expected_power_df
task_utils_df = self._get_expected_task_utils_df()
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4876, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/tests/scheduler/eas_behaviour.py", line 263, in _get_expected_task_utils_df
cols = dict(
File "/home/leoy/Work2/tools/lisa/lisa/tests/scheduler/eas_behaviour.py", line 264, in <genexpr>
task_util(task, wlgen_task)
File "/home/leoy/Work2/tools/lisa/lisa/tests/scheduler/eas_behaviour.py", line 236, in task_util
df = self.trace.ana.rta.df_phases(task, wlgen_profile=rtapp_profile)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 1679, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 541, in wrapper
raise e
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4867, in wrapper
trace = self.trace
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 1679, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 541, in wrapper
raise e
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4867, in wrapper
trace = self.trace
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 1679, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 541, in wrapper
raise e
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4867, in wrapper
trace = self.trace
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 1679, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 541, in wrapper
raise e
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4867, in wrapper
trace = self.trace
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 1679, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 541, in wrapper
raise e
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4867, in wrapper
trace = self.trace
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 1679, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 541, in wrapper
raise e
File "/home/leoy/Work2/tools/lisa/lisa/utils.py", line 527, in catch
x = f(*args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/tests/base.py", line 1757, in trace
return trace.get_view(self.trace_window(trace), clear_base_cache=True)
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4876, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/tests/base.py", line 1666, in trace_window
phase_start_df = trace.ana.rta.df_rtapp_phases_start(
File "/home/leoy/Work2/tools/lisa/lisa/analysis/_proxy.py", line 59, in wrapper
return x(**kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4876, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/analysis/rta.py", line 446, in df_rtapp_phases_start
return self._get_rtapp_phases('start', task, wlgen_profile=wlgen_profile)
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4876, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/analysis/rta.py", line 295, in _get_rtapp_phases
df = self.df_rtapp_loop(task, wlgen_profile=wlgen_profile)
File "/home/leoy/Work2/tools/lisa/lisa/trace.py", line 4876, in wrapper
return f(self, *args, **kwargs)
File "/home/leoy/Work2/tools/lisa/lisa/analysis/rta.py", line 288, in df_rtapp_loop
df = df.groupby(['__pid', '__comm'], observed=True).apply(f)
File "/home/leoy/Work2/tools/lisa/.lisa-venv-3.8/lib/python3.8/site-packages/pandas/core/groupby/groupby.py", line 1414, in apply
result = self._python_apply_general(f, self._selected_obj)
File "/home/leoy/Work2/tools/lisa/.lisa-venv-3.8/lib/python3.8/site-packages/pandas/core/groupby/groupby.py", line 1455, in _python_apply_general
values, mutated = self.grouper.apply(f, data, self.axis)
File "/home/leoy/Work2/tools/lisa/.lisa-venv-3.8/lib/python3.8/site-packages/pandas/core/groupby/ops.py", line 761, in apply
res = f(group)
File "/home/leoy/Work2/tools/lisa/lisa/analysis/rta.py", line 272, in f
pid, comm = df.event_name
File "/home/leoy/Work2/tools/lisa/.lisa-venv-3.8/lib/python3.8/site-packages/pandas/core/generic.py", line 5583, in __getattr__
return object.__getattribute__(self, name)
AttributeError: 'DataFrame' object has no attribute 'event_name'
Finished UUID=3f5859f6813049e8900548ee470df711 in 15.85s (cumulative: 129.19s) EnergyModelWakeMigration[board=hikey960]:test_task_placement
^^^^^^^^^^^^^^^^^^^
EXCEPTION (AttributeError): 'DataFrame' object has no attribute 'event_name'
```
https://gitlab.arm.com/tooling/lisa/-/issues/1747Question: lisa-wltest-series on Hikey960 with Android2022-06-10T05:41:11ZDarryl GreenQuestion: lisa-wltest-series on Hikey960 with Android*Created by: Leo-Yan*
Hi there,
I think now lisa-wltest-series is obsolete for Hikey960 with Android system.
The main reason is the command 'lisa-wltest-series' need to build the boot.img with different kernel commits, and compari...*Created by: Leo-Yan*
Hi there,
I think now lisa-wltest-series is obsolete for Hikey960 with Android system.
The main reason is the command 'lisa-wltest-series' need to build the boot.img with different kernel commits, and comparing the performance and power data for these commits. But we could see now AOSP starts to support GKI kernel so that all the ko modules are required to be rebuilt when every time we build Linux kernel image, and we need to copy the Image and .ko modules into AOSP repository to generate the final boot.img and super.img. From my understanding, when every time we update the boot image, we also need to flash super.img as well so can update all kernel modules (.ko files). The details for building kernel Image and boot.img is on the page: https://source.android.com/setup/build/devices#960kernel.
When I read the document tools/wltests/README.md, it gives information which is obsolete. So could you give some suggestion for this part? I personally think this is a very useful feature for EAS (or scheduler tunning).
Thanks!https://gitlab.arm.com/tooling/lisa/-/issues/1832when I run typical_experiment.ipynb, The program is stuck at this position::-...2022-05-17T20:00:01ZDarryl Greenwhen I run typical_experiment.ipynb, The program is stuck at this position::-> 2022-05-15 21:35:28,547 INFO : lisa.target.Target : Freezing all tasks except: sh,adbd,usb,transport,thermal-engine,watchdogd*Created by: accsky*
**Describe the bug**
A clear and concise description of what the bug is.
![image](https://user-images.githubusercontent.com/51768765/168476245-194f56c0-ae66-40dd-a8c4-e6cbd44436d6.png)
**To Reproduce**
Steps t...*Created by: accsky*
**Describe the bug**
A clear and concise description of what the bug is.
![image](https://user-images.githubusercontent.com/51768765/168476245-194f56c0-ae66-40dd-a8c4-e6cbd44436d6.png)
**To Reproduce**
Steps to reproduce the behavior:
* what part of LISA is being used (synthetic tests, WA-related features, etc.)
* what kind of target is being used (linux, android, etc.)
* what code is being run if that is a custom script using LISA APIs
**Expected behavior/what was the purpose of the experiment**
A clear and concise description of what you expected to happen.
Giving the overall purpose of the script you are trying to get to work can help us identify which part of the API you may benefit from much more quickly.
**Logs of the error**
info and debug can be found under the artifacts as INFO.log and DEBUG.log.
The header of the log is useful as it gives plenty of information on python version and similar things.
*Review the log and strip out any credential that you are not comfortable sharing before posting*
**Additional context**
Add any other context about the problem here.
https://gitlab.arm.com/tooling/lisa/-/issues/1833When run typical_experiment.ipynb. :: FtraceCollector(target, events=events, ...2022-05-15T15:07:56ZDarryl GreenWhen run typical_experiment.ipynb. :: FtraceCollector(target, events=events, buffer_size=10240, output_path=trace_path). Error:cat: /sys/kernel/debug/tracing/available_events: No such file or directory*Created by: accsky*
**Describe the bug**
A clear and concise description of what the bug is.
![image](https://user-images.githubusercontent.com/51768765/168477932-ec199dff-e5d4-40b6-a0e4-97bcfa4aa5eb.png)
![image](https://user-ima...*Created by: accsky*
**Describe the bug**
A clear and concise description of what the bug is.
![image](https://user-images.githubusercontent.com/51768765/168477932-ec199dff-e5d4-40b6-a0e4-97bcfa4aa5eb.png)
![image](https://user-images.githubusercontent.com/51768765/168477925-51884aa3-f52c-40d8-a0da-c8ad772ffedc.png)
**To Reproduce**
Steps to reproduce the behavior:
* what part of LISA is being used (synthetic tests, WA-related features, etc.)
* what kind of target is being used (linux, android, etc.)
* what code is being run if that is a custom script using LISA APIs
**Expected behavior/what was the purpose of the experiment**
A clear and concise description of what you expected to happen.
Giving the overall purpose of the script you are trying to get to work can help us identify which part of the API you may benefit from much more quickly.
**Logs of the error**
info and debug can be found under the artifacts as INFO.log and DEBUG.log.
The header of the log is useful as it gives plenty of information on python version and similar things.
*Review the log and strip out any credential that you are not comfortable sharing before posting*
**Additional context**
Add any other context about the problem here.
https://gitlab.arm.com/tooling/lisa/-/issues/1826On Android S, the tracing folder is "/sys/kernel/tracing/" ,not "/sys/kernel...2022-04-25T11:18:03ZDarryl GreenOn Android S, the tracing folder is "/sys/kernel/tracing/" ,not "/sys/kernel/debug/tracing/"*Created by: accsky*
Capture ftrace on Android S, how to adapt? *Created by: accsky*
Capture ftrace on Android S, how to adapt? https://gitlab.arm.com/tooling/lisa/-/issues/1741Fail to build kernel module 'sched_tp' with the mainline kernel2021-11-23T16:48:54ZDarryl GreenFail to build kernel module 'sched_tp' with the mainline kernel*Created by: Leo-Yan*
**Describe the bug**
When I tried to build kernel module 'sched_tp' to enable ftrace events for scheduler, it failed to build .ko file.
**To Reproduce**
Steps to reproduce the behavior:
$ cd $lisa_folder
$ s...*Created by: Leo-Yan*
**Describe the bug**
When I tried to build kernel module 'sched_tp' to enable ftrace events for scheduler, it failed to build .ko file.
**To Reproduce**
Steps to reproduce the behavior:
$ cd $lisa_folder
$ source init_env
$ cd tools/kmodules/
$ ./build_module ~/Work/opensource/linux/ ./sched_tp/
* what part of LISA is being used (synthetic tests, WA-related features, etc.)
tools/kmodules
* what kind of target is being used (linux, android, etc.)
Mainline kernel
* what code is being run if that is a custom script using LISA APIs
n/a
**Logs of the error**
```
[LISAShell kmodules] \> ./build_module ~/Work/opensource/linux/ ./sched_tp/
Building module for ARCH=arm64
make: Entering directory '/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp'
pahole -C file:///home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/vmlinux_deps.txt /home/leoy/Work/opensource/linux/vmlinux > vmlinux_deps.h
pahole -C file:///home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/vmlinux.txt /home/leoy/Work/opensource/linux/vmlinux > vmlinux.h
make -C /home/leoy/Work/opensource/linux M=/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp modules
make[1]: Entering directory '/home/leoy/Work/opensource/linux'
CC [M] /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp.o
In file included from /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:10,
from /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_events.h:18,
from /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp.c:8:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/vmlinux_deps.h:33:2: error: unknown type name ‘cpu_stop_fn_t’
33 | cpu_stop_fn_t fn; /* 16 8 */
| ^~~~~~~~~~~~~
In file included from /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_events.h:18,
from /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp.c:8:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘rq_of’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:17:15: error: dereferencing pointer to incomplete type ‘struct cfs_rq’
17 | return cfs_rq->rq;
| ^~
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘cpu_of’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:31:11: error: dereferencing pointer to incomplete type ‘struct rq’
31 | return rq->cpu;
| ^~
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘task_group_is_autogroup’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:42:13: error: dereferencing pointer to incomplete type ‘struct task_group’
42 | return !!tg->autogroup;
| ^~
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘sched_tp_rd_span’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:169:16: error: dereferencing pointer to incomplete type ‘struct root_domain’
169 | return rd ? rd->span : NULL;
| ^~
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘autogroup_path’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:58:1: error: control reaches end of non-void function [-Werror=return-type]
58 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘task_group_is_autogroup’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:46:1: error: control reaches end of non-void function [-Werror=return-type]
46 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘rq_of’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:18:1: error: control reaches end of non-void function [-Werror=return-type]
18 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘cpu_of’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:35:1: error: control reaches end of non-void function [-Werror=return-type]
35 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘sched_tp_cfs_rq_avg’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:103:1: error: control reaches end of non-void function [-Werror=return-type]
103 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘sched_tp_rq_nr_running’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:178:1: error: control reaches end of non-void function [-Werror=return-type]
178 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘sched_tp_rd_span’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:173:1: error: control reaches end of non-void function [-Werror=return-type]
173 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘sched_tp_rq_avg_irq’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:148:1: error: control reaches end of non-void function [-Werror=return-type]
148 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘sched_tp_rq_avg_dl’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:139:1: error: control reaches end of non-void function [-Werror=return-type]
139 | }
| ^
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h: In function ‘sched_tp_rq_avg_rt’:
/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp_helpers.h:130:1: error: control reaches end of non-void function [-Werror=return-type]
130 | }
| ^
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:273: /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp/sched_tp.o] Error 1
make[1]: *** [Makefile:1847: /home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp] Error 2
make[1]: Leaving directory '/home/leoy/Work/opensource/linux'
make: *** [Makefile:18: build] Error 2
make: Leaving directory '/home/leoy/Work2/Develop/tools/lisa/tools/kmodules/sched_tp'
```