On Fri, Apr 25, 2025 at 07:35:36AM +0000, Gabriele Monaco wrote: > 2025-04-25T06:35:09Z Nam Cao <[email protected]>: > > On Thu, Apr 24, 2025 at 03:55:34PM +0200, Gabriele Monaco wrote: > >> I quickly tried the same with the other monitor comparing the number of > >> errors with the page_faults generated by perf, but that didn't make too > >> much sense. Perhaps I'm doing something wrong here though (the number > >> reported by perf for page faults feels a bit too high). > >> > >> perf stat -e page-faults -e rv:error_pagefault stress-ng --cyclic 1 > > > > This command run a non-real-time thread to do setup, and a cyclic real-time > > thread. The number of pagefaults of each thread would be roughly > > proportional to the code size executed by each thread. As the non-real-time > > thread's code size is bigger, it sounds reasonable that the number of > > pagefaults is greater than the number of monitor's warnings. > > Mmh I guessed something like that, although numbers were a bit out of > proportion (e.g. 500 page-faults and 8 errors), but again, I didn't check > too carefully what happens under the hood.
Keep in mind that the non-real-time thread is calling into glibc. While the real-time thread is a small loop doing nanosleep. > > I tested the monitor on a real system. My system has some real-time audio > > processing processes (pipewire, firefox running youtube), yours also > > should. > > That's a good point, also I didn't mention I was running these tests in a > VM (virtme-ng), so the system stress is minimal and perhaps the setup > triggers some different oddities (filesystems are overlays and some other > things are set up differently from a real system). Oddities are good, they make some corner cases appear. Evidently I need to torture the monitors much more, let's see what else shows up.. Best regards, Nam
