linux-kernel - Re: [PATCH v4 20/22] rv: Add rtapp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250425093309.RkeoCUBC@linutronix.de>
Date: Fri, 25 Apr 2025 11:33:09 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
	john.ogness@...utronix.de
Subject: Re: [PATCH v4 20/22] rv: Add rtapp_sleep monitor

On Fri, Apr 25, 2025 at 07:35:36AM +0000, Gabriele Monaco wrote:
> 2025-04-25T06:35:09Z Nam Cao <namcao@...utronix.de>:
> > 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