VIS, a small Linux/x86_64 tool for CPU jitter, SMI evidence, and runtime placement reports

VIS, a small Linux/x86_64 tool for CPU jitter, SMI evidence, and runtime placement reports

[Ahmet Cevdet Çelik]

   Hi,

   My name is Ahmet Cevdet Celik. I am developing a small open-source
   Linux/x86_64 project called VIS:

   https://github.com/AhmetCevdetCelik/V-S

   VIS is an experimental deterministic performance evidence layer. It is
   not intended to replace existing Linux RT tools such as cyclictest,
   hwlatdetect, rtla, ftrace, or perf. My current goal is to build a small
   toolchain that measures what it can, reports what it cannot measure, and
   produces machine-readable evidence around CPU noise and runtime 
placement.

   Current components:

   - vis-jitter:
     RDTSCP-based CPU jitter measurement, with IA32_SMI_COUNT based
     rejection of SMI-contaminated measurement windows.

   - vis-doctor:
     System diagnosis and advisory reports. It inspects CPU topology,
     SMT, governor, isolation, HugePages, environment mode
     (bare metal / VM / container), MSR availability, RDTSCP support,
     and reports evidence quality.

   - vis-run:
     Reads a Doctor runtime policy, temporarily runs a workload under the
     selected CPU affinity profile, and emits a post-run attestation.

   - vis-compare:
     Runs the same workload under different runtime profiles and can
     capture user-defined workload metrics for comparison.

   The main idea is:

       critical workloads should not run on hardware blindly;
       the system should collect evidence about CPU noise, firmware-level
       interruptions, scheduler/runtime effects, and placement decisions.

   At this stage VIS is Linux/x86_64 only and very much experimental. It
   depends on Linux interfaces such as /proc, /sys, sched_setaffinity, and
   on x86 timing/MSR mechanisms for some measurements. I am aware that this
   limits the scope and that SMI/MSR evidence is not always available,
   especially in virtualized or restricted environments.

   I would appreciate technical feedback from the Linux RT community,
   especially on these questions:

   1. Is this kind of evidence/reporting layer useful next to existing
      tools such as cyclictest, hwlatdetect, rtla, ftrace, and perf?

   2. Is the current SMI-contaminated-window rejection approach technically
      reasonable, or is it too strict / misleading for noisy systems?

   3. Should VIS try to import or align with rtla/hwlat/perf data rather
      than implementing more sensors itself?

   4. What would be the most useful next step for making this relevant to
      real-time Linux users? For example:
      - better integration with rtla/hwlat,
      - cgroups/cpuset based runtime containment,
      - perf counter evidence,
      - or clearer report/schema design.

   I am not looking to make exaggerated claims. The project is early, and
   I would rather get criticism now than build in the wrong direction.

   Thanks for your time.

   Best regards,
   Ahmet Cevdet Celik

Re: VIS, a small Linux/x86_64 tool for CPU jitter, SMI evidence, and runtime placement reports

[Ahmed S. Darwish]

On Thu, 14 May 2026, Ahmet Cevdet Çelik wrote:
>
> I would appreciate technical feedback from the Linux RT community,
> especially on these questions:
>
> 1. Is this kind of evidence/reporting layer useful next to existing
>    tools such as cyclictest, hwlatdetect, rtla, ftrace, and perf?
...
> 3. Should VIS try to import or align with rtla/hwlat/perf data rather
>    than implementing more sensors itself?
>
> 4. What would be the most useful next step for making this relevant to
>    real-time Linux users? For example:
>    - better integration with rtla/hwlat,
...
>  I am not looking to make exaggerated claims. The project is early, and
>  I would rather get criticism now than build in the wrong direction.
>

I would personally recommend that you add the missing bits to the existing
official tools instead: rtla, ftrace, perf, etc.

By submitting your new additions there, you will also get feedback from the
experts on each topic.

Random personal GitHub projects really die off after a while.

All the best,
Ahmed