Open Source Summit India 2026

In the modern practice of Platform Engineering (PE), performance has traditionally been viewed as an outcome of optimization rather than an architectural principle. This session presents a Performance-by-Design methodology that integrates intelligent scaling, guardrails, feedback-driven control loops within Internal Developer Platforms (IDPs). Instead of reacting to incidents, we design platforms that manage latency, throughput, cost efficiency, and stability by applying policy-driven autoscaling, SLO-aware metrics, and Kubernetes-native mechanisms constantly. The session outlines a reference architecture with observability pipelines, custom metrics, horizontal pod autoscaling, and platform guardrails to ensure a self-regulating cloud-native operating environment. We show how performance constraints can be codified into golden paths; teams will inherit optimized defaults. Attendees will receive a structured framework to convert performance from reactive tuning task to platform capabilities - increasing reliability, decreasing resource consumption and allowing scalable innovation on enterprise cloud-native ecosystems.

Modern Kubernetes platforms generate massive volumes of logs, events, metrics, and reconciliation signals, yet developers still struggle to answer a basic question: why did my deployment fail? At Comcast, operating large-scale internal Kubernetes platforms, failures often span platform abstractions, custom controllers, policies, and cluster runtime behavior—making manual diagnosis slow and unreliable.

This talk explores how AI can act as a diagnostic layer in Kubernetes platforms, focusing on failure explanation rather than detection. It presents architectural patterns for correlating platform intent with Kubernetes signals and translating complex control-plane behavior into clear, human-readable explanations and actionable guidance. Attendees will learn how AI can augment platform engineers, improve developer trust, and significantly reduce time-to-resolution without becoming another opaque system.

A broken deployment is every developer's nightmare. Standard CI/CD pipelines fail on minor typos or missing dependencies, forcing engineers to dig through logs and push manual fixes. What if your infrastructure could safely fix itself?
This session explores the transition from rigid automation to AI-driven recovery, introducing the "Pipeline Doctor" in Python: an agentic AI system acting as a self-healing safety net for your repositories.
Allowing AI to write production code sounds terrifying, doesn't it? This is why this talk prioritizes strict execution guardrails. Attendees will learn to set strict tool-calling boundaries around the LLM that securely restrict its capabilities.
Watch me intentionally break a live deployment pipeline to demonstrate how the autonomous agent catches the failure, securely verifies its fix inside an isolated GitHub Actions sandbox, and submits a Pull Request paired with an auto-generated Root Cause Analysis (RCA). Attendees will leave with a practical, open-source blueprint to build self-healing pipelines in their own environments.

Linux kernel development has long since moved past the point of lacking contributors, with around 2,000 developers participating in each release and up to 330 first-time committers [1]. What the development process is missing, however, are reviewers and maintainers.

If you ever thought that becoming a Linux kernel maintainer was something reserved for members of a secret kernel lodge, join this talk in which we will explain why - and how - you should become a Linux kernel maintainer, with a focus on improving the Embedded Linux ecosystem.

Intention of this talk is not only present Krzysztof's ideas how to become Linux kernel maintainer, but also bring discussion with the audience, hoping more senior kernel maintainers will join and participate with their ideas and comments. Thus it could be considered a sort of half-Birds of Feather session.

[1] LWN.net: Some 6.18 development statistics, https://lwn.net/Articles/1046966/

Performance profiling in virtualized environments has traditionally required trade-offs between accuracy and overhead. Mediated PMU, a recent change to Linux's built-in KVM hypervisor, fundamentally changes this by providing guests direct access to hardware Performance Monitoring Units (PMUs).

This talk will:
- Explore the differences between the old and new approaches.
- Demonstrate a reduction in PMU virtualization overhead and improvement in profiling accuracy.
- Discuss the key trade-off: while guests gain direct hardware access, the host loses the ability to profile guest workloads through perf.

This talk is ideal for virtualization engineers, kernel developers, and anyone performing performance analysis in cloud or virtualized environments who needs accurate, low-overhead profiling data.

Virtualizing Performance Monitoring Units (PMUs) requires careful coordination between hardware and software to provide guests with accurate, low-overhead performance monitoring while maintaining security and isolation.

This talk examines what it takes to virtualize PMU features, focusing on a hardware-assisted approach built on the upstream Mediated PMU framework in the Linux kernel.
This talk will
1. Explore motivations such as protecting confidential guests, reducing context-switch overhead, and maintaining host-guest boundaries.
2. Cover hardware support for selective interception, direct interrupt delivery to guests, and automated guest state management, as well as software handling of host state for registers not saved by hardware.
3. Demonstrate performance monitoring counters and instruction-based sampling virtualization, showing how hardware automation improves software-based state management and strengthens security for confidential computing workloads.

This talk is aimed at virtualization engineers, kernel developers, and performance analysts working in cloud or confidential computing environments.

What if every repository in your organisation inherited security, compliance and AI-driven automation the moment it adopted your CI/CD pipeline - with zero extra configuration?

In this session, I'll walk through a fully reusable, open-source-first CI/CD pipeline system built on GitHub Actions/GitLab CI that enforces security and quality gates end-to-end. We'll cover how secret scanning, OWASP Dependency Check, OWASP Dependency-Track, OSV Scanner for container images and SonarQube - community edition for SAST are wired together as non-negotiable pipeline steps - not afterthoughts. I'll demonstrate how Dependabot, Projen and how strict controls actively prevent supply chain attacks before they happen.

Beyond security, the pipeline handles semantic versioning, Cloud deployments, package publishing, artifact management and test report hosting - all reusable across multiple repos.

The talk concludes with the AI layer: using LLMs to auto-generate changelogs, trigger SonarQube self-healing agents and track deployment history for incident response. Attendees will leave with a practical blueprint for adopting OSS tools to build pipelines that are secure, intelligent and built to scale.

ML platforms are powerful, but not always easy to use. A data scientist might understand their model well, yet struggle with Kubernetes configs, SDK APIs, or GPU scheduling. The result is friction — and a lot of “Can someone submit this job for me?” messages.

In this talk, I’ll introduce Kubeflow MCP Server — a Model Context Protocol bridge that exposes the Kubeflow SDK as AI-callable tools. Instead of writing Python or YAML, users can train and manage workloads through natural conversation, while the MCP layer handles validation and policy enforcement underneath.

KEP: https://github.com/kubeflow/community/pull/937

We’ll show:
Turning Kubeflow operations into structured MCP tools
Pre-flight checks that catch resource mismatches before submission
Persona-based filtering so data scientists get safe access while admins keep full control
A two-phase confirmation pattern to avoid accidental large GPU allocations

This session explores what it means for ML infrastructure to become agent-friendly — without compromising governance or cluster safety.

Who owns testing standards in your project? Who decides release gates? Who pays the cost of test debt?

Many open source projects cannot answer clearly. Not because maintainers do not care, but because test health responsibility emerges informally rather than being explicitly defined. What remains informal becomes nobody's obligation until it turns into everyone's problem.

Examining governance docs, contributor guidelines and issue discussions from Linux kernel, Kubernetes, Apache and OpenStack, this talk surfaces a recurring pattern: investing in CI alone does not clarify who owns test health. Kubernetes has a testing SIG and extensive CI, yet flaky test discussions reveal uncertainty about who can enforce fixes.

Four practical steps projects can adopt:

Make testing ownership explicit in governance and contributing documentation.
Define release quality gates that are written, versioned and enforced.
Designate CI health stewardship the way projects designate release managers.
Track flaky test debt the way projects track open issues.

Open source conferences focus on tools. This talk focuses on ownership: a framework for identifying and closing gaps in test health responsibility.

Modern CPUs rely on spatial locality when fetching fixed-size cache lines, but kernel structures are often laid out without reflecting runtime access patterns. Frequency-based reordering groups hot fields together but misses a key insight: two high-frequency fields accessed at different times can still waste cache capacity through eviction between accesses. We propose access-affinity-based reordering fields accessed close together in time should be placed close together in memory.

We trace field-level accesses on struct rq, compute co-access frequencies within a short time window, and build an access-affinity graph where edge weights reflect temporal co-access. Hierarchical clustering derives reorderings that collocate temporally correlated fields within cache lines. Evaluated on waitstressor, cache misses dropped from 36.2B (13.9%) to 25.1B (9.4%), with idle_cpu() misses falling from 6.40% to 3.11%. Tool automates this analysis across kernel structures. We explore HTM-based tracing and MemFriend for scalable profiling. Key discussion areas: workload selection per structure, 64B vs 128B line layouts, false-sharing avoidance, and extending this methodology beyond struct rq.

FRED (Flexible Return and Event Delivery) represents a modernization of x86 processor event handling, replacing the decades-old IDT (Interrupt Descriptor Table) mechanism and eliminating its inherent design flaws. This advancement introduces new low-latency ring transitions that establish complete supervisor or user context. FRED uses stack-based event delivery with integrated event data and introduces dedicated ERETU and ERETS return instructions.

These enhancements resolve longstanding issues related to atomicity, consistency, and nested exception handling in x86 architecture. This results in faster, more reliable and robust event processing through simplified system software and reduced attack surface.

The talk will start with a look at traditional IDT event delivery and the issues it creates. Then, we’ll dive into the FRED overview, covering briefly its terminology, design, and core mechanisms. To wrap up, we’ll touch advanced topics like virtualization and GS segment handling, highlighting why FRED is a major leap forward for modern x86 architecture.

Pressure Stall Information (PSI) is excellent for detecting CPU/memory/I/O contention via trigger windows and user-space polling, but it intentionally avoids attributing pressure to individual tasks. In practice, during severe pressure the “who did it?” question is hardest to answer: systems are sluggish, logs are noisy, and user-space observers can be delayed or miss the critical moment.
Building on PSI work presented at LPC 2024, this session introduces an optional, configurable, lightweight In-Kernel PSI Auto Monitor that captures thread-level contributors exactly when configured PSI thresholds are breached. The design avoids changes to PSI fast paths, requires no always-on daemon, and records contending tasks using existing kernel mechanisms and tracepoints.
I will share upstream patch status and experimental results from real embedded workloads, including PREEMPT_RT scenarios, quantifying trigger latency, overhead, and improvements in root-cause identification. Finally, I will demo a GenAI-assisted pipeline that parses monitor logs, generates timelines, and produces actionable summaries to speed up pressure-event debugging.

Hardware cryptographic accelerators have been essential in embedded SoCs for decades, yet upstream Linux maintainers are removing/rejecting them. The extinction is underway.

In 2025, maintainers began removing async crypto API support, targeting engines from major SoC vendors for deprecation.[1][2] Software wins on throughput for typical payloads. ARMv8/v9 Crypto Extensions amplify this advantage. Performance-wise, maintainers have a point.

But benchmarks miss critical security. Hardware provides what software cannot: DPA/EMA side-channel attack resistance[3], hardware-backed wrapped key isolation, and secure boundaries essential for physically accessible devices. With PQC transition, hardware crypto becomes more essential.

The crisis: maintainers remove features certifications require and contracts mandate, forcing vendor forks from mainline.

We address making the security case and finding compromises satisfying both maintainability and embedded security.

[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/