Temporary Container Filesystems With Local Swapping for OOM Prevention

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing container build processes incur significant waste of computer resources due to unnecessary sync operations and IO related to file system changes that are disregarded if the build fails, and traditional temporary file systems risk out-of-memory failures when exceeding memory limits.

Innovation Solution

Implement a temporary file system with local memory swapping capabilities, allowing data to be maintained in volatile memory during builds and enabling individualized memory swapping configurations for containers, including swap file specifications and memory limits, to manage memory usage efficiently.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If sync operations are performed during container build to ensure data persistence, then data reliability is improved, but computer resources are wasted since changes are disregarded on build failure

Engineering Contradiction:
Improvedata persistenceVSAvoidcomputer resource waste
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent introduces a temporary file system as an intermediary layer between container memory and persistent storage. This temporary file system absorbs sync operations during builds, preventing them from propagating to permanent storage. The intermediary allows builds to appear reliable (data is written somewhere) while actually discarding changes on failure, thus resolving the contradiction between data persistence and resource waste.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of manufacture

If traditional temporary file systems are used, then ease of implementation is improved, but out-of-memory failures occur when memory limits are exceeded

Engineering Contradiction:
Improveease of implementationVSAvoidmemory management stability
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The patent implements dynamic memory management for the temporary file system by allowing unprivileged users to configure memory limits and swap file specifications. The system dynamically adjusts between volatile memory and swap files based on available resources, transforming the static memory allocation of traditional tmpfs into a flexible, adaptive system that prevents out-of-memory failures while maintaining ease of implementation through configurable parameters.

Inventive Principle:
Principle #15Dynamics

3Productivity

If memory usage is increased during container builds, then build speed is improved, but out-of-memory failures risk increases

Engineering Contradiction:
Improvebuild speedVSAvoidmemory availability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent extends the memory management problem from a single dimension (volatile memory only) to multiple dimensions by introducing swap files as a secondary storage dimension. This allows the system to increase memory usage for faster builds while having a fallback dimension (swap files) to prevent out-of-memory failures, effectively resolving the trade-off between build speed and memory reliability.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS20250265124A1Manageable input/output (IO) for volatile container memory
Publication Date: 2025.08.21 RED HAT INC
  • US20250265124A1 patent drawing
  • US20250265124A1 patent drawing
  • US20250265124A1 patent drawing

AI summary

Disclosed are techniques for a temporary file system with local memory swapping capabilities. An example method includes receiving a mount request comprising a request to mount a temporary file system for a container. The mount request indicates that the temporary file system is to reside in volatile memory of the container and includes one or more local memory-swapping specifications to be applied to the container. The method also includes receiving write operations addressed to the container. The method also includes determining, by a processing device, whether to initiate local memory swapping for the container by comparing memory usage of the container with a threshold memory usage, and in response to determining to initiate local memory swapping, swapping data from the volatile memory of the container to a local swap file specified by the one or more local memory-swapping specifications included in the mount request.