On Mon, Jul 18, 2022 at 12:34 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > [...] > > I think I figured this one out (the CI failure). I set max_entries for > the maps in the test to 10, because I have 1 entry per-cgroup, and I > have less than 10 cgroups. When I run the test with other tests I > *think* there are other cgroups that are being created, so the number > exceeds 10, and some of the entries for the test cgroups cannot be > created. Using hashmap to store per-cgroup data is only a short-term solution. We should work on extending cgroup-local storage to tracing programs. Maybe as a follow-up change once cgroup_iter is merged. > in the bpf trace produced by my test, and the error turned out to be > -E2BIG. I increased max_entries to 100 and it seems to be consistently > passing when run with all the other tests, using both test_progs and > test_progs-no_alu32. > > Please find a diff attached fixing this problem and a few other nits: > - Return meaningful exit codes from the reclaimer() child process and > check them in induce_vmscan(). > - Make buf and path variables static in get_cgroup_vmscan_delay() > - Print error code in bpf trace when we fail to create a bpf map entry. > - Print 0 instead of -1 when we can't find a map entry, to avoid > underflowing the unsigned counters in the test. > > Let me know if this diff works or not, and if I need to send a new > version with the diff or not. Also let me know if this fixes the > failures that you have been seeing locally (which looked different > from the CI failures). > Yosry, I also need to address Yonghong's comments in the cgroup_iter patch, so we need to send v4 anyway. Hao > Thanks! > [...]
