Performance tools often print a short setup recipe before an advanced analysis:

sudo sysctl -w kernel.perf_event_paranoid=0
sudo sysctl -w kernel.kptr_restrict=0

Because the settings appear together, they are easy to interpret as one “enable profiling” switch. They are not. They control different evidence boundaries.

• perf_event_paranoid helps determine which performance events an unprivileged process may collect.
• kptr_restrict helps determine which kernel addresses may be exposed and resolved.
• ELF/DWARF symbols determine how user-space addresses map to functions and source lines.
• Kernel debug information determines how resolved kernel addresses map to deeper source-level detail.

You can have permission to collect a sample but lack enough address information to name its kernel function. You can resolve your C application perfectly while being denied system-wide PMU counters. You can see a kernel symbol but lack its source line. A useful profiler must report these as separate capabilities.

What Is A Kernel Pointer?

The Linux kernel is compiled code loaded into protected address space. Kernel functions, modules, objects, stacks, and data structures occupy virtual addresses. Internally, the kernel uses pointers to refer to them just as a C program uses pointers in user space.

Interfaces such as /proc/kallsyms, selected /proc files, tracing output, and kernel logs may expose representations of those addresses. A profiler can associate a sampled instruction pointer with a kernel function only if it has a trustworthy address-to-symbol map.

That is the purpose of kernel.kptr_restrict: it places restrictions on exposing kernel addresses through /proc and other interfaces. It does not change where the kernel is loaded and does not modify the application being profiled.

What Do Values 0, 1, And 2 Mean?

Why Is Kernel Address Disclosure A Security Concern?

Kernel Address Space Layout Randomization, or KASLR, is the kernel counterpart to user-space ASLR. During boot, the kernel chooses randomized virtual locations for the kernel image and, depending on the architecture and configuration, other kernel regions. The next boot can produce a different layout even though the kernel build is unchanged.

KASLR does not normally shuffle every function independently. Functions in one kernel image retain build-defined offsets relative to that image. What changes is the base location of the image or region. If an attacker knows the exact kernel build and learns the live address of one known function, subtracting its known offset can reveal information about the randomized base and help predict other addresses.

Setting kptr_restrict=0 does not disable KASLR, grant root access, execute code, read arbitrary kernel memory, or unlock hardware counters. It relaxes selected kernel-address disclosure rules. That information may make another vulnerability easier to exploit, which is why a shared workstation or production host should not relax it casually.

For profiling, the tradeoff is direct: named kernel attribution requires enough address information to map a sample back to a kernel function. On a trusted development machine, an administrator may temporarily allow that evidence. On a multi-user or production machine, leaving the restriction enabled and accepting unresolved kernel frames may be the safer result.

Does User-Space Profiling Need It?

Usually, no. If CKE runs as an ordinary executable and the question is “Which generated C function consumes CPU time?”, the profiler can attribute user-space instruction pointers using the executable and shared libraries’ ELF symbols. With debug information, it can map those functions to source lines.

Typical user-space questions include:

• Which GEMM, GEMV, attention, normalization, or quantization function is hot?
• Which generated model layer calls it?
• How much time is spent in CKE versus libc or OpenMP?
• Which loops vectorized?
• What is the call stack inside the target process?

These do not inherently require visible kernel pointers. They may still require perf_event permission, depending on whether sampling uses software events, hardware PMUs, call stacks, or a restricted distribution policy.

When Does Kernel Attribution Matter?

CPU AI performance does not stop at the application boundary. A generated kernel may be fast while the complete process loses time elsewhere:

• page faults while touching model weights;
• scheduler migration and context switching;
• futex waits inside a thread pool;
• NUMA page placement and memory policy;
• filesystem reads during model loading;
• interrupt, network, storage, or driver activity;
• kernel work caused by memory mapping and allocation.

A mixed user/kernel profile can sample these paths. If kernel addresses cannot be resolved, the tool may group time under an unknown kernel module or an “outside any known module” label. The samples still happened; their names are missing.

What perf_event_paranoid Controls Instead

Linux exposes performance monitoring through perf_event_open. Depending on kernel and security policy, kernel.perf_event_paranoid limits unprivileged access to per-process events, kernel-space samples, system-wide collection, raw tracepoints, CPU PMUs, and uncore devices.

This is the gate that commonly determines whether VTune’s driverless event-based sampling can collect the requested data. Intel documents values of zero or lower for system-wide and uncore-oriented analyses. Memory Access and HPC Characterization may need uncore counters for DRAM and interconnect bandwidth. Advisor roofline also needs the counters required to place loops against compute and memory ceilings.

Lowering perf_event_paranoid can expose process behavior and system-level performance information to local users. That is a separate security tradeoff from exposing kernel addresses.

Which Setting Does Each Analysis Need?

Why The Same VTune Command Can Work On One CPU And Fail On Another

This distinction became concrete while onboarding a CKE contributor. The deep VTune command worked on Ubuntu with a 12th-generation Core i7, but VTune rejected the event configuration on a Core i5-5200U system before collection began:

vtune: Error: Option 'pmu-type' received value from the next argument:
'--event-config=CPU_CLK_UNHALTED.THREAD,...'

The Core i5-5200U is a fifth-generation Broadwell mobile processor. The command also requested V8_VTUNE_DEEP=1, which adds VTune Memory Access analysis after the ordinary hotspot collection. That deeper analysis depends on a compatible processor PMU, a VTune release that still describes that PMU correctly, a supported operating-system environment, and permission to collect the requested events.

The error is not evidence that kptr_restrict hid an application function. VTune was parsing or configuring the hardware-event collection itself. Lowering kptr_restrict cannot add a missing event definition, repair a mismatched --pmu-type invocation, or make an older processor supported by a newer collector.

Intel's support boundaries change between VTune releases and analysis types. Intel's 2025.1 requirements explicitly limited current CPU analysis support to Ice Lake and newer client/server processors and directed older processors to older VTune releases. Newer release notes describe broader baseline execution requirements, but that does not promise that every PMU-dependent analysis is available on every older processor. The installed vtune --version, selected analysis, kernel, distribution, and processor must be recorded together.

For the Broadwell system, retry without the deep collection:

REPORT_MODEL_DIR="$HOME/.cache/ck-engine-v8/models/unsloth--gemma-3-270m-it-GGUF"

make profile-v8-vtune \
  V8_MODEL="$REPORT_MODEL_DIR" \
  V8_PERF_RUNTIME=cli \
  V8_PREP_WITH_PYTHON=0 \
  V8_WITH_VTUNE=1 \
  V8_VTUNE_DEEP=0

If that still fails, capture the target contract before changing security policy:

vtune --version
uname -r
cat /etc/os-release
lscpu
ls /sys/bus/event_source/devices/
sysctl kernel.perf_event_paranoid kernel.kptr_restrict

Inspect Before Changing Anything

sysctl kernel.kptr_restrict
sysctl kernel.perf_event_paranoid
sysctl kernel.dmesg_restrict
head /proc/kallsyms
perf stat -- true

The results should become profiler metadata. A report that says “VTune hotspots” but omits collection mode, sampling driver, sysctls, kernel version, and symbol state is difficult to reproduce.

A Safer Temporary Workflow

Record the original values:

old_kptr=$(sysctl -n kernel.kptr_restrict)
old_perf=$(sysctl -n kernel.perf_event_paranoid)
printf 'original kptr=%s perf=%s\n' "$old_kptr" "$old_perf"

Change only what the selected analysis requires:

sudo sysctl -w kernel.perf_event_paranoid=0
sudo sysctl -w kernel.kptr_restrict=0

Run the bounded collection, then restore the original values:

sudo sysctl -w kernel.kptr_restrict="$old_kptr"
sudo sysctl -w kernel.perf_event_paranoid="$old_perf"

A sysctl -w change normally lasts until another change or reboot. Writing a file under /etc/sysctl.d makes the policy persistent and should be presented as an administrator decision, not a routine profiler button.

What The CKE Profiler Integration Should Do

CKE's profiling workflow is part of the project's reproducibility contract, not an automatic system-tuning service. The V8 runbook connects model execution, generated artifacts, IR reports, and profiler commands.

1. Detect the current kernel, PMU, driver, symbol, and sysctl capabilities.
2. Default to the least-privileged user-space analysis that answers the question.
3. Explain exactly which missing evidence an additional permission would enable.
4. Never change sysctls automatically.
5. Offer temporary commands before persistent configuration.
6. Record original and collection-time values in every profiler artifact.
7. Distinguish “collection unavailable” from “kernel symbols unresolved.”
8. Prefer Intel’s controlled sampling-driver group where appropriate instead of broad host-wide access.
9. Provide restoration commands and verify the restored state.

Primary References

• Linux kernel sysctl documentation defines kptr_restrict and its values.
• Intel VTune security considerations explains profiler privilege and perf_event_paranoid risks.
• Intel VTune kernel analysis explains /proc/kallsyms, kptr_restrict, and kernel-module resolution.
• Intel’s driverless profiling recipe separates system-wide collection, uncore access, and kernel symbol resolution.
• Intel VTune 2025.1 system requirements document the Ice Lake-and-newer CPU-analysis boundary for that release and direct older processors to older VTune versions.
• Intel Core i5-5200U specifications identify the contributor target as a fifth-generation Broadwell processor.

CKE Reading Path

• What Is the C Kernel Engine? explains why CKE generates inspectable C from model structure and explicit kernel contracts.
• CKE documentation is the canonical map of architecture, supported paths, evidence, and current limitations.
• Profiling CKE covers the practical perf, flame graph, VTune, and Advisor workflow.
• CKE V8 runbook provides the current commands for model preparation, generated runtimes, IR reports, and profiling.
• CKE Discord is the community channel for questions, coordination, and deeper technical discussion.
• CKE source repository contains the compiler, circuits, kernel maps, generated-runtime tooling, tests, and contribution path.