diff --git a/FrOSCon26/Antrag.txt b/FrOSCon26/Antrag.txt index a8c610c..f48aa9d 100644 --- a/FrOSCon26/Antrag.txt +++ b/FrOSCon26/Antrag.txt @@ -12,47 +12,50 @@ OpenSource-Projekt lösen mussten: eine große Menge Video-Daten effizient einle Vor diesem Hintergrund möchte ich das neue IO_URING Kernel-Interface erläutern und mit vereinfachten Code-Beispielen in C++ zeigen, wie es in eine Applikation eingebunden werden kann. Rudimentäre C++ Kenntnisse sollten genügen, um dem -Vortrag zu folgen. +Vortrag zu folgen, Kennnisse in Systemprogrammierung werden nicht vorrausgesetzt. Für die eigentliche Darstellung rechne ich mit 40 Minuten. Kurzfassung ~~~~~~~~~~~ -IO_URING is a fairly new IO interface in the Linux kernel. -It marks a paradigm shift in how the kernel is interacted with. -Instead of passing control thorough an interface function to enter into kernel mode, -messages are passed asynchronously. +io_uring is a fairly new I/O interface in the Linux kernel. +It represents a shift in how applications interact with the kernel. +Instead of transferring control through a system-call interface into kernel mode, +operations are submitted asynchronously through shared queues. -In this talk, patterns for dealing with asynchronous IO are discussed and a setup to handle -high volume file reading using this framework is demonstrated with code examples in C++. +This talk discusses patterns for dealing with asynchronous I/O and demonstrates a setup +for high-volume file reading using this framework, illustrated with code examples in C++. -Lumiera is a video editing application under development in C++ -- and is used here to -illustrate that asynchronous I/O can play a key role in achieving high throughput for video processing. +Lumiera is a video editing application under development in C++ and serves here +as a real-world example showing how asynchronous I/O can play a key role in achieving +adequate throughput for video processing. Langfassung ~~~~~~~~~~~ -The usual simple way of reading data from a file is to just invoke a `read()` function, directly -getting the data in response. This function is accessible as part of the programming language's -standard library, yet in the end it maps down onto a function of the OS kernel. And while this -form of reading data from a file is easy to handle, in terms of program logic, it has the downside -that the current thread is blocked, for an unknown period of time, until the data is ready. +The usual straightforward way to read data from a file is to invoke a read() +function and receive the requested data directly in response. While this function +is typically exposed through the programming language's standard library, it ultimately +maps to a system call provided by the OS-kernel. Although this approach is simple in +terms of program logic, it has the disadvantage that the calling thread is blocked, +for an unknown amount of time, until the data becomes available. -Blocking is particularly problematic in high-performance computing, as it means losing control -over the timings and leaving resources unused. Various interfaces and frameworks have been -developed over time to improve this, both for network communication and for file operations. -The Linux kernel system call interface IO_URING, adopted in kernel version 5.1 (2019) and -gradually expanded since then, takes these efforts one step further and provides an uniform -framework for various kinds of IO operations: The client code instructs the kernel to perform -some IO related task by sending it a message, and the kernel returns the completed work items -via a different queue. +Blocking behaviour is particularly problematic in high-performance applications, because it +reduces control over execution timing and may leave computational resources idle. Various +interfaces and frameworks have been developed over time to address this issue, both for +network communication and for file operations. The Linux kernel system call interface +io_uring, adopted in kernel version 5.1 (2019) and gradually expanded since then, +takes these efforts one step further by providing a uniform framework for many kinds of +I/O operations: Client code submits requests to the kernel via shared queue, while +completed work items are returned asynchronously through a second queue. -In theory, it is possible to achieve an extreme throughput or very low latency; yet in practice, -it proves quite challenging to structure the client code accordingly to achieve these goals. -In our use case, related to rendering video frames based on the arrangement made by the film -editor, expensive computations need to be chained-up behind the IO operations, all involving -a massive amount of data. The talk will discuss some common solution patterns, and the approach -taken by the Lumiera project to cope with this situation. A simplified demo level setup will -then be explained with code examples in C++ +In theory, this model allows extremely high throughput and very low latency. +In practice, however, structuring client code to achieve these goals remains challenging. +In our use case -- rendering video frames based on the timeline arrangement made by the +film editor -- expensive computations must be chained behind I/O operations, all together +involving a massive amount of data. +The talk discusses common solution patterns and presents the approach taken by the +Lumiera project to address these challenges. A simplified demonstration setup +will then be explained using code examples in C++. diff --git a/FrOSCon26/FrOSCon.26.mm b/FrOSCon26/FrOSCon.26.mm index 93c2680..bfbd70b 100644 --- a/FrOSCon26/FrOSCon.26.mm +++ b/FrOSCon26/FrOSCon.26.mm @@ -474,7 +474,7 @@ - + @@ -537,10 +537,14 @@ - - + + + + + +