# Linux Kernel Configurations at Scale: A Dataset for Performance and Evolution Analysis

Heraldo Borges, Juliana Alves Pereira, Djamel Eddine Khelladi, Mathieu Acher

## ► To cite this version:

Heraldo Borges, Juliana Alves Pereira, Djamel Eddine Khelladi, Mathieu Acher. Linux Kernel Configurations at Scale: A Dataset for Performance and Evolution Analysis. EASE 2025 - Evaluation and Assessment in Software Engineering, Jun 2025, Istambul, Turkey. pp.1-10. hal-05063560

HAL Id: hal-05063560

https://hal.science/hal-05063560v1

Submitted on 12 May 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Linux Kernel Configurations at Scale:
A Dataset for Performance and Evolution Analysis

Heraldo Borges
Univ Rennes

Inria, CNRS, IRISA
Rennes, France

heraldo.pimenta-borges-filho@irisa.fr

Djamel Eddine Khelladi
Univ Rennes

Inria, CNRS, IRISA
Rennes, France

djamel-eddine.khelladi@irisa.fr

Juliana Alves Pereira
Pontifical Catholic University of Rio de Janeiro

Rio de Janeiro, Brazil
juliana@inf.puc-rio.br

Mathieu Acher
Univ Rennes

Inria, CNRS, IRISA
Rennes, France

mathieu.acher@irisa.fr

## Abstract

Configuring the Linux kernel to meet specific requirements, such as binary size, is highly challenging due to its immense complexity—with over 15,000 interdependent options evolving rapidly between versions. Although several studies have explored sampling strategies and machine learning methods to understand and predict the impact of configuration options, a comprehensive and large-scale dataset that encompasses multiple kernel versions, along with detailed quantitative measurements, remains lacking in the literature. To bridge this gap, we introduce *TuxKConfig*, an accessible collection of kernel configurations that spans multiple kernel releases (including versions from 4.13 to 5.8). This dataset, gathered through automated tools and builds, comprises more than 240,000 kernel configurations systematically labeled with compilation outcomes and binary sizes. By providing detailed records of configuration evolution and the intricate interplay among kernel options, our dataset supports innovative research in feature subset selection, machine learning-based prediction models, and transfer learning between kernel versions. Throughout the paper, we describe how the dataset has been made easily accessible via OpenML and demonstrate how it can be used with just a few lines of Python code to assess AI-based techniques (e.g., supervised machine learning). We expect this dataset to enhance reproducibility and drive new insights into configuration-space analysis at a scale that presents a unique opportunity and inherent challenges, advancing our understanding of the Linux kernel's configurability and evolution.

## CCS Concepts

* Software and its engineering → Software configuration management and version control systems; Software performance; Software evolution.

## Keywords

Configurable Systems, Linux Kernel, Kernel Configuration, Tabular Data; Software Evolution, Dataset

## 1 Introduction

Ensuring that software systems meet specific functional and non-functional requirements—such as binary size—is critical in software

engineering. This challenge is particularly pronounced in highly configurable systems like the Linux kernel, which includes over 15,000 interdependent options evolving rapidly across versions, with use-cases spanning IoT devices and supercomputers [1, 5, 21]. For instance, in embedded systems such as IoT devices, reducing the kernel's binary size is crucial for operation on hardware with limited memory, while in high-performance servers, compilation time can be a critical bottleneck in development cycles. Beyond Linux, practitioners often face difficulties selecting optimal configurations due to the combinatorial explosion of possible configurations and subtle, unpredictable interactions among these options [2, 7, 8, 13, 17, 24–27, 33, 35, 40].

Traditional approaches to exploring Linux kernel configurations, such as manual tuning, documentation review, and community expertise, are valuable, but inherently limited. These methods struggle with scalability, version-specific knowledge, and incomplete documentation, leaving developers vulnerable to suboptimal decisions and unforeseen interactions between configuration options [5, 21]. Consequently, practitioners lack systematic insights into configuration behavior, hindering efficient kernel optimization [6].

Recent research efforts, including TuxML [4] and machine learning-based predictive modeling [6, 8, 17, 21, 26, 35], have made strides by sampling configurations and predicting kernel properties like binary size or build success. However, existing datasets typically cover single kernel versions or narrowly defined metrics, limiting their applicability to studies of configuration evolution, cross-version detection of non-functional properties, and complex option interactions [7].

To address these gaps, we present the *TuxKConfig*, a systematically curated dataset encompassing over 200,000 configurations from multiple Linux kernel versions (including releases from 4.13 to 5.8). We reuse and adapt existing tools, such as TuxML [4], to perform large-scale builds using a cluster of machines. Our dataset uniquely captures configuration evolution, build outcomes, and kernel binary sizes, allowing for broader generalization and deeper empirical evidence into the Linux kernel's configuration space.

To construct the *TuxKConfig* dataset, we rely on extensive random sampling using make randconfig, a standard tool to generate valid Linux kernel configurations while respecting dependency
constraints. This approach provides a broad coverage of the con-
figuration space in different versions. Although we do not apply
guided sampling, the large number of collected configurations—over
200K—ensures substantial diversity. In future extensions, incorpo-
rating guided strategies could complement our current dataset by
targeting specific option interactions, performance behaviors, or
rarely activated features.

Data-driven methodologies enabled by *TuxKConfig* provide a scalable and systematic approach to understanding kernel configurability. By leveraging extensive historical data and performance measurements, researchers and practitioners can develop predictive models that assist in selecting configurations tailored to specific goals, such as minimizing binary size, optimizing compilation time, or enhancing robustness. Moreover, *TuxKConfig* also supports longitudinal studies that analyze the evolution of configuration impacts over time. This is particularly valuable for system maintainers and developers, where existing documentation may lag behind rapid kernel development, omitting crucial details about new or deprecated options. Thus, the Linux kernel dataset enables significant advancements in predictive modeling, transfer of learning between kernel versions, and automated detection of problematic combinations of options [7, 21]. By supporting transfer learning scenarios, the dataset allows models trained on older kernel versions to adapt and make accurate predictions for newer releases, reducing the computational burden of generating training data from scratch. It also supports the investigation of robust sampling strategies and informed feature selection techniques, offering practitioners reliable guidance for kernel configuration decisions in real-world scenarios, such as embedded systems optimization.

The *TuxKConfig* dataset<fnref n="1" /> is publicly available on OpenML [41], along with its associated artifacts, promotes replication, validation and extension of existing research. As we will show and thanks to OpenML, it is possible to import our datasets and explore AI-based techniques with a few lines of Python code. These empirical data contribute to a structured investigation of how kernel options interact and evolve across versions, offering a valuable resource for researchers studying feature interactions, predictive modeling, and automated configuration tuning. All figures, tables, and code examples presented in this paper are available in the GitHub repository at https://github.com/heraldoborges/tuxkconfig/. This repository provides a Jupyter notebook that replicates the analyses and visualizations, facilitating reproducibility and further exploration of the *TuxKConfig* dataset.

## 2 Dataset Construction

The construction of this dataset involved a systematic automated
process to ensure scalability, consistency, and reproducibility. In
the following, we detail the collection and preprocessing phases.

2.1 Data Collection

Data were gathered from seven Linux kernel versions: 4.13 (Sep-
tember 2017), 4.15 (January 2018), 4.20 (December 2018), 5.0 (March
2019), 5.4 (November 2019), 5.7 (May 2020), and 5.8 (August 2020).
These versions reflect significant evolutionary milestones, includ-
ing security enhancements (e.g., Meltdown/Spectre mitigations in

4.15) and large-scale updates (e.g., 5.8's extensive commits) [21]. We leveraged the TUXML tool [4] that facilitated the process, automating configuration generation, compilation, and measurement within a Docker environment.

For each version, the `randconfig` utility generated valid random
configurations for the `Kconfig` dependencies. Compilations aimed at
the x86_64 architecture using GCC 6.3, producing the `vmlinux` file, a
statically linked executable, whose size was measured in megabytes.
The number of configurations varied from 92,471 (4.13) to 21,923
(5.8), totaling 243,232 configurations. Compilation times averaged
261 seconds per configuration on 16-core Intel Xeon machines (3.7
GHz, 64 GB RAM), with over 15,000 hours of processing for version
4.13 alone [21]. Docker ensured portability across heterogeneous
clusters.

## 2.2 Preprocessing

Raw data were cleaned and transformed to enhance usability: [4]

* **Filtering:** Non-tristate options (300-320 per version, e.g. integers or strings) were filtered out as they are marginal in most configuration scenarios and have limited influence on overall kernel behavior [6, 21].

* **Encoding:** Tristate values ('y' = enabled, 'n' = disabled, 'm' = module) were binarized ('y' = 1, 'n' or 'm' = 0), as 'n' and 'm' showed similar effects on configuration measurement of non-functional properties [21].

* **Derived Feature:** A column summing enabled options ('y') was added, inspired by prior work [3], aiding predictive modeling.

* **Constant Removal:** Options with uniform values across the dataset were excluded, reducing noise.

* **Baseline Configuration:** The binary sizes of the compiled kernel images (vmlinux) span a wide range of values. For each version, we also include `tinyconfig`, which produces a minimal kernel to serve as a lower bound in our evaluation.

Preprocessing was executed in Python with Pandas and NumPy, producing structured CSV files. The setup ensured hardware independence, leveraging Docker's standardized environment.

3 Linux Kernel Dataset

The dataset comprises CSV files—one file for each version—totaling approximately 2 GB compressed. Each file includes:

* Version: Identifier (e.g., "4.13").

* **Date/Time:** Compilation timestamp.

* **Option1, ..., OptionN:** Binary values (0 or 1) for options (e.g., CONFIG_HAMACHI, CONFIGaul).

* **Binary Size (MB):** vmlinux size.

* **Compilation Time (s):** Build duration.

* **Sum_ENABLED_OPTIONS:** Count of 'y' options.

Table 1 and Figure 1 provide a detailed overview of kernel binary
size characteristics across versions 4.13 to 5.8. The table summa-
rizes the minimum and maximum kernel binary sizes, highlighting
the variations in configurability. Figure 1 further illustrates the
distribution of kernel binary sizes for each version using box plots.
The median binary size is represented by the central line within
each box, while the interquartile range (IQR) captures the middle

<footnote n="1">¹Available on OpenML https://openml.org/search?type=data&status=active&id=46749</footnote>
<table><caption>**Table 1: Characteristics of Each Version**</caption><thead><tr><td>Version</td><td>Options</td><td>Configurations</td><td>Min/Max Size (MB)</td></tr></thead><tbody><tr><td>4.13</td><td>12,502</td><td>92,471</td><td>7.0 / 1698.1</td></tr><tr><td>4.15</td><td>9,445</td><td>39,391</td><td>11.0 / 1783.8</td></tr><tr><td>4.20</td><td>10,209</td><td>23,489</td><td>11.0 / 2035.5</td></tr><tr><td>5.0</td><td>10,313</td><td>19,952</td><td>11.0 / 1869.5</td></tr><tr><td>5.4</td><td>10,833</td><td>25,847</td><td>11.1 / 1959.4</td></tr><tr><td>5.7</td><td>11,358</td><td>20,159</td><td>11.1 / 1906.0</td></tr><tr><td>5.8</td><td>11,550</td><td>21,923</td><td>11.1 / 1905.1</td></tr></tbody></table>

50% of the data, showing the range where most kernel binary sizes fall. The whiskers extend to indicate the broader distribution, and numerous outliers, represented by densely grouped points beyond the whiskers, highlight configurations with exceptionally large binaries.

<figure><img src="image_2.png" /><figcaption>**Figure 1: Boxplot of binary size distribution (MB) across versions 4.13 to 5.8.**</figcaption></figure>

Across versions, the distributions reveal a consistent trend. Although most configurations result in moderate-sized kernel binaries, certain configurations lead to significantly larger binaries, often exceeding 800 MB. The presence of numerous outliers suggests that specific kernel options can dramatically increase binary size. This variability highlights the diversity and complexity of kernel configuration effects, reinforcing the importance of dataset-driven analysis, as manual tuning alone may not effectively capture the full spectrum of configuration performance.

The dataset includes multiple measurements of kernel binary size, capturing both the original uncompressed kernel binary size and its compressed forms. Specifically, it records the size of the vmlinux binary—representing the statically linked, uncompressed Linux kernel—along with various compressed kernel image sizes typically used in deployment scenarios. These compressed variants include standard compression algorithms such as gzip (GZIP -vmlinux and GZIP -bzImage), bzip2 (BZIP2 -vmlinux and BZIP2 -bzImage), LZMA (LZMA -vmlinux and LZMA -bzImage), and XZ (XZ-vmlinux). The bzImage notation, historically referring to a self-extracting compressed kernel image used particularly on x86 architectures, is provided under multiple compression algorithms

to facilitate the exploration of kernel sizes under different compression methods. By offering these multiple binary size measurements, the dataset enables researchers and practitioners to analyze and understand how configuration options impact the kernel's footprint, considering different compression choices that are crucial in various practical deployment environments [6].

## 4 Tasks and Research Opportunities

The TuxKConfig dataset opens a wide range of research opportunities and practical applications due to its comprehensive representation of Linux kernel configurations. Unlike typical tabular datasets—often characterized by limited features and simpler structures—TuxKConfig stands out through its scale and complexity, capturing the intricate, interdependent configuration space of an evolving real-world software system. This enables research into both well-explored areas, such as predictive modeling and transfer learning, and emerging opportunities, including hybrid scenarios and tool development, each offering unique insights into kernel configurability and its broader implications [21, 32].

In the following subsections, we present these research directions in detail, highlighting their significance, associated challenges, and potential contributions. The complete set of scripts for the research directions described, including additional examples for the Optimization and Performance Specialization areas, is available in our supplementary material<fnref n="2" />, which provides comprehensive support for reproducing and extending the presented techniques.

### 4.1 Performance Prediction

Performance prediction in configurable systems aims to estimate non-functional properties, such as execution time, memory usage, or binary size, based on a given configuration. This task is critical in software engineering, where understanding the impact of configuration options enables developers to optimize systems for specific requirements. Research has extensively explored this problem using machine learning (ML) techniques, ranging from regression models to deep learning, to predict results in large configuration spaces [6, 7, 32]. However, the scale and complexity of real-world systems often challenge the precision and efficiency of these methods, particularly when training data is limited or the configuration space is vast and interdependent [4, 20]. The goal is to map input configurations (e.g., feature selections) to measurable outputs (e.g., performance metrics), typically evaluated using metrics like Mean Absolute Error (MAE) or Mean Relative Error (MRE).

In the context of the Linux kernel, performance prediction becomes particularly compelling due to its highly configurable nature, with over 15,000 options evolving across versions. Previous studies have demonstrated its applicability not only to binary size, but also to compilation time, robustness, or even potential metrics such as boot time [6, 21]. For example, predicting binary size can guide developers in producing lightweight kernels for resource-constrained environments, while predicting compilation time can optimize build processes [6]. The challenge lies in the kernel's combinatorial configuration space and interdependencies, which render exhaustive exploration infeasible and demand ML models that generalize well with minimal training data [4, 5].

<footnote n="2">²https://github.com/heraldoborges/tuxkconfig/</footnote>
The *TuxKConfig* dataset specifically enables performance prediction by providing over 243,000 configurations across seven Linux kernel versions (4.13 to 5.8), each with detailed binary size measurements. In this context, we focus on predicting the binary size (in MB) of the vmlinux file for a given configuration within a specific version, such as 5.8, without considering cross-version adaptations. The expected input is a vector of binary-encoded options (e.g., CONFIG_HAMACHI = 1 or 0), and the output is a continuous value representing the size of the kernel, evaluated using the MAPE to assess the precision of the prediction. To illustrate, we provide a basic Python example using the OpenML dataset of *TuxKConfig* version 5.8 (ID: 46744), employing a Linear Regression baseline:

```python
from sklearn.linear_model import LinearRegression
from sklearn.model_selection import train_test_split
import openml
import numpy as np

# Known targets to exclude from training features
targets = ["vmlinux", "GZIP-bzImage", "GZIP-vmlinux", "GZIP",
            "BZIP2-bzImage", "BZIP2-vmlinux", "BZIP2", "LZMA-bzImage",
            "LZMA-vmlinux", "LZMA", "XZ-bzImage", "XZ-vmlinux",
            "XZ", "LZO-bzImage", "LZO-vmlinux", "LZO", "LZ4-bzImage",
            "LZ4-vmlinux", "LZ4"]

# Fetch TuxKConfig v5.8 from OpenML
dataset = openml.datasets.get_dataset(46744)
data,_,_,_ = dataset.get_data()

# Separate features (options) and target (vmlinux)
X = data.drop colunms=known_targets, errors="ignore")
y = data["vmlinux"]

# Split the data into training and test sets
X_train, X_test, y_train, y_test = train_test_split(X, y,
    test_size=0.2, random_state=42)

# Train and evaluate a simple linear regression model
model = LinearRegression()
model.fit(X_train, y_train)
predictions = model Predict(X_test)

# Calculate MAPE
mape = np.abs((predictions - y_test)/y_test).mean() * 100
print(f"MAPE: {mape:.2f}%")
```

In this example, applying to 21,923 configurations from version 5.8, the baseline yields a MAPE of 88.49%, indicating a significant percentage deviation that suggests room for improving prediction precision with more sophisticated models. This aligns with the findings that simple models struggle with kernel complexity, while more sophisticated approaches (e.g. selection of subsets of features or ensemble methods) can improve precision [5, 20]. The scale of the *TuxKConfig* dataset, far exceeding typical tabular datasets in feature count [14], poses a unique challenge: Can state-of-the-art predictors scale effectively and maintain accuracy with limited training samples? Researchers can leverage this dataset to benchmark and refine ML techniques, fostering advancements in performance prediction for configurable systems.

## 4.2 Transfer Learning

Transfer learning in configurable software systems seeks to harness knowledge acquired from one domain or version to enhance predictions in a related yet distinct context. This approach proves especially valuable when data for a target version is limited, enabling models trained on extensive source data to adapt effectively

to new scenarios [21]. Existing studies underscore its utility in minimizing the need for exhaustive retraining. In addition, these studies highlight improvements in predictive performance in evolving software variants. Nevertheless, the approach faces challenges related to divergent feature sets and shifting data distributions [6, 32]. In particular, Martin et al. [21] demonstrate its promise in navigating expansive configuration spaces, where models must adjust to changing dependencies and options' impacts. The task entails using configuration data and associated performance metrics from a source version as inputs to forecast outcomes—such as size or time—in a target version, with accuracy gauged through metrics like MAPE [6, 20].

When applied to the Linux kernel, transfer learning emerges as a strategic method to cope with its dynamic evolution, marked by frequent updates to thousands of configuration options, the introduction of new features, and shifting interdependencies across releases. Previous work has illustrated the potential of leveraging configuration data to predict various system properties, such as binary size and, to a lesser extent, compilation time [21]. Although more speculative metrics such as boot time remain challenging to model, they represent promising directions for future investigation [4, 21]. In contrast to the single version focus on performance prediction outlined in Section 4.1, this approach capitalizes on historical data to span multiple releases, addressing the difficulty of maintaining predictive accuracy amid kernel evolution [5]. This capability is vital for developers seeking to streamline configuration optimization across successive versions without the burden of collecting fresh data for each release.

The *TuxKConfig* dataset facilitates this task by offering a comprehensive collection of more than 243,000 configurations spanning seven Linux kernel versions (4.13 to 5.8), each accompanied by precise binary size measurements. Here, transfer learning involves training a model on configurations from prior versions, such as 5.4, to predict the vmlinux binary size (in MB) for a subsequent version, like 5.8. The input comprises binary-encoded option vectors from the source versions, while the output is the predicted size in the target version, evaluated using MAPE. Below is a Python example utilizing *TuxKConfig* datasets from OpenML—versions 5.4 (ID: 46742) as sources, and 5.8 (ID: 46744) as the target—employing a Hist Gradient Boosting regressor model, known for handling large datasets and capturing complex interactions among options:

```python
from sklearn.ensemble import HistGradientBoosting Regressor
from sklearn.model_selection import train_test_split
import openml
import pandas as pd
import numpy as np

# Target columns to exclude from input features
targets = ["vmlinux", "GZIP-bzImage", "GZIP-vmlinux", "GZIP",
            "BZIP2-bzImage", "BZIP2-vmlinux", "BZIP2", "LZMA-bzImage",
            "LZMA-vmlinux", "LZMA", "XZ-bzImage", "XZ-vmlinux",
            "XZ", "LZO-bzImage", "LZO-vmlinux", "LZO", "LZ4-bzImage",
            "LZ4-vmlinux", "LZ4"]

# Load datasets from OpenML
X_504d = openml.datasets.get_dataset(46742) # v5.4
X_trgd = openml.datasets.get_dataset(46744) # v5.8
X_504,_,_,_ = X_504d.get_data("dataframe")
X_trg,_,_,_ = X_trgd.get_data self. (dataset_format="dataframe")

# Extract targets
```
```
y_504 = X_504["vmlinux"]
y_trg = X_trg["vmlinux"]
X_504 = X_504.drop colu mns = targets, errors = "ignore")
X_trg = X_trg.drop colu mns = targets, errors = "ignore")

# Feature engineering
for df in [X_504, X_trg]: df["nb_yes"] = df. eq(1). sum (axis = 1)

# Align features between source and target
common_features = X_504. columns. intersection (X_trg. columns)
X_504 = X_504[common_features]
X_trg = X_trg[common_features]

# Drop rows with NaN in features or targets
src df = pd. concat([X_504, y_504], axis = 1). dropna ()
trg df = pd. concat([X_trg, y_trg], axis = 1). dropna ()

X_source = src df. drop colu mns = ["vmlinux"])
y_source = src df["vmlinux"]
X_trg = trg df. drop colu mns = ["vmlinux"])
y_trg = trg df["vmlinux"]

# Train and predict
model = HistGradientBoostingRegr essor (random_state = 42)
X_source_train, X_source_test, y_source_train,
y_source_test = train_test_split (X_source, y_source,
test_size = 0.2, random_state = 42)
model. fit(X_source_train, y_source_train)
predictions = model. predict (X_trg)

# Compute MAPE
map e = np. mean(np. abs((predictions - y_trg)/y_trg ))*100
print(f"MAPE (v5.4 - v5.8): {map e:.2f}%")
```

This example, drawing on 46,318 configurations from version 5.4 to predict 23,159 configurations in version 5.8, yields a MAPE of approximately 23.31% [21]. Although this result remains significantly better than intraversion predictions using simpler linear models (as illustrated in Section 4.1), it highlights the inherent challenges posed by evolving configuration dependencies and interactions between kernel releases [5, 21]. These findings reinforce the value of the *TuxKConfig* dataset, with its multiversion scope, as a robust resource to further refine transfer learning methods and deepen our understanding of how kernel configurations evolve across versions. Furthermore, identifying which configuration options most significantly affect prediction accuracy between versions remains crucial, motivating interpretability studies (Section 4.3) to better capture critical configuration elements over time.

## 4.3 Interpretability

Interpretability in machine learning models applied to configurable systems seeks to uncover which configuration options most significantly influence system behavior, offering insights into their relative importance. This task is essential for demystifying complex predictive models, where opaque algorithms—such as neural networks or ensemble models like random forests—often obscure the contribution of individual features [20, 32]. Prior research has grappled with the instability of feature importance measures, noting that results can fluctuate across model runs due to randomness or interdependencies among options [4, 6]. Acher et al. [5] emphasize that identifying a small subset of pivotal features can explain much of the variability in system outcomes, yet achieving consistent and actionable insights remains elusive in vast configuration spaces [5].

In highly configurable systems like the Linux kernel, interpretability shifts focus to pinpointing which of the over 15,000 options drive

key properties—be it binary size, compilation time, or other performance indicators. Beyond merely predicting outcomes, as explored in Sections 4.1 and 4.2, this task aims to illuminate why certain predictions hold, helping developers prioritize configuration adjustments [21]. For instance, understanding whether CONFIG_PCI outweighs CONFIG_HAMACHI in affecting kernel size can guide optimization efforts. However, the scale of the kernel and the intricate dependencies of the options complicate this analysis, as standard methods, such as the importance of the features of tree-based models, may yield inconsistent rankings in executions [20]. This challenge, raised in previous discussions, underscores the need for robust techniques to extract and filter meaningful patterns from such expansive datasets.

Using version 5.8 of the *TuxKConfig* dataset, available in OpenML (ID: 46744) and containing detailed binary size data per configuration, we focus on identifying the options that most influence the size of the generated vmlinux. Interpretability here entails taking binary-encoded option vectors as input and producing a weighted ranking of influential configuration options as output. To illustrate this approach, we apply a Random Forest regressor and assess the configuration options via their feature importance scores:

```
from sklearn. ensemble. import RandomForestRegr essor
from sklearn. model_selection. import train_test_split
import openml
import pandas as pd
import numpy as np

targets = ["vmlinux", "GZIP-bzImage", "GZIP-vmlinux", "GZIP",
"BZIP2-bzImage", "BZIP2-vmlinux", "BZIP2", "LZMA-bzImage",
"LZMA-vmlinux", "LZMA", "XZ-bzImage", "XZ-vmlinux",
"XZ", "LZO-bzImage", "LZO-vmlinux", "LZO", "LZ4-bzImage",
"LZ4-vmlinux", "LZ4"]

# TuxKConfig v5.8 (dataset ID: 46744)
dataset = openml. datasets. get_dataset(46744)
X,_,_ = dataset. get_data()
y = X["vmlinux"]

# Remove known target
X = X. drop colu mns = targets, errors = "ignore")

# Train model for feature importances
X_train, X_test, y_train, y_test = train_test_split (X, y,
test_size = 0.2, random_state = 42)
model =RandomForestRegr essor(100, random_state =42)
model. fit(X_train, y_train)
y_pred = model. predict (X_test)

# MAPE
map e = np. mean(np. abs((y_test -y_pred)/y_test ))*100
print(f"MAPE: {map e:.2f}%")

# Compute feature importances from the trained model
importances = model. feature_importances_
features = X. columns

# The top 5 most influential configuration options
top_indexes = importances. argsort()[-5:][:-1]
top5 = [(features[i], importances[i]) for i in top_indexes]
for feature, score in top5: print(f"{feature}:
{score:.4f}")
```

Running this analysis on 21,923 configurations from version 5.8 reveals that options such as DEBUG_INFO (0.2067), active_options (0.2004), and DEBUG_INFO_REduced (0.1647) strongly influence kernel binary size. Additionally, DEBUG_INFO_SPLIT (0.1235) and X86_NEED_RELOCS (0.0829) also significantly contribute to variability.
These findings align with prior observations that a small subset of configuration options tends to dominate kernel size variability [5]. The cumulative importance of these top-five features accounts for approximately 78% of the total variance, clearly highlighting their critical role in determining kernel size. The predictive model achieved an MAPE of approximately 11.04%, demonstrating a satisfactory predictive accuracy. However, the consistency of feature importance across different kernel versions remains a recognized challenge [20]. Building upon insights from transfer learning discussed in Section 4.2, which illustrated evolving option influences between kernel releases, this interpretability analysis provides a foundational step toward feature selection. By pinpointing these influential options, we set the stage for efficiently reducing the configuration space, a task explored further in Section 4.4 through targeted feature selection methods.

## 4.4 Feature Selection

Feature selection addresses the challenge of paring down the configuration options in complex software systems to a subset that retains essential predictive power while easing computational demands. This task emerges as a cornerstone in managing high-dimensional spaces, where analyzing all possible features exhaustively becomes computationally prohibitive [32]. Research has shown that many options contribute redundantly or minimally to system behavior, and by isolating a core set, one can streamline analysis without sacrificing accuracy [5, 6]. Acher et al. [5] illustrate this by demonstrating that a fraction of features can account for most performance variation, though selecting such a subset requires balancing relevance against the risk of overlooking subtle interactions [20]. The process begins with a complete configuration dataset as input and yields a reduced feature set as output, typically assessed by the prediction accuracy achieved with the selected options.

Within the realm of configurable systems like the Linux kernel, feature selection tackles the daunting scale of over 15,000 options, aiming to simplify analyses of properties such as binary size, compilation time, or system robustness. Although interpretability (Section 4.3) highlights which options wield the greatest influence, feature selection shifts the focus to curating a practical subset for downstream tasks like prediction or tuning [6]. This reduction proves critical when adapting models across versions or crafting efficient kernels, yet the kernel's dense web of dependencies complicates the endeavor—discarding features may inadvertently disrupt key relationships [21]. The challenge lies in devising methods that scale effectively and remain stable in such complex scenarios.

Using version 5.8 of the *TuxKConfig* dataset from OpenML (ID: 46744), feature selection targets the reduction of options for predicting vmlinux binary size. The input consists of binary-encoded configuration vectors from 21,923 instances, and the output is a trimmed set of influential options, evaluated using MAPE of a model trained on this reduced subset. Below is a Python example employing a Random Forest-based for both feature selection and prediction to identify critical configuration options and assess their predictive performance.

```python
import pandas as pd
import numpy as np

targets = ["vmlinux", "GZIP-bzImage", "GZIP-vmlinux", "GZIP",
            "BZIP2-bzImage", "BZIP2-vmlinux", "BZIP2", "LZMA-bzImage",
            "LZMA-vmlinux", "LZMA", "XZ-bzImage", "XZ-vmlinux",
            "XZ", "LZO-bzImage", "LZO-vmlinux", "LZO", "LZ4-bzImage",
            "LZ4-vmlinux", "LZ4"]

dataset = openml.datasets.get_dataset(46744)
X,_,_ = dataset.get_data dataset_format="dataframe")
y = X["vmlinux"]
X = X.drop colunms=targets, errors="ignore")

# Split data
X_train, X_test, y_train, y_test = train_test_split(X, y,
    test_size=0.2, random_state=42)

# Use RandomForest for feature selection
selector = SelectFromModel(RandomForestRegressor(
    n_estimators=100, random_state=42))
selector.fit(X_train, y_train)
selected_features = X.columns[selector.get_support()]

# Evaluate with selected features
model = RandomForestRegressor(n_estimators=100,
    random_state=42)
model.fit(X_train[selected_features], y_train)
y_pred = model predict(X_test[selected_features])

# MAPE evaluation
mape = np.mean(np abs((y_test-y_pred)/(y_test))) * 100
print(f"MAPE - Feature selection: {mape:.2f}%")
```

This example effectively reduced the initial 11,531 options to approximately 130 by employing the Select From Model feature selection technique in combination with a Random Forest Regressor. This method automatically selects features whose importance, calculated by the Random Forest model, exceeds a predefined threshold. Specifically, we adopted the default threshold ("mean"), thus retaining only options whose importance exceeded the average value. These results align with findings by Acher et al. [5], who similarly observed that a relatively small subset of options is often sufficient to achieve accurate kernel size predictions. A subsequent model trained on this reduced subset achieved a Mean Absolute Percentage Error (MAPE) of approximately 9.74%, demonstrating an improvement in predictive accuracy compared to the 11.04% obtained using the complete set of features presented in Section 4.3. This suggests that the feature selection process successfully identified and retained the most informative options, resulting in both a simplified and a more accurate predictive model. Although cross-version consistency requires further investigation [20], this substantial feature reduction, based on the interpretability analysis of Section 4.3, enables optimizing minimal kernels by prioritizing critical options such as SSB Drivers, BNX2, DMA COHERENT_POOL, ARCH HAS_FORCE DMA_UNENCRYPTED, and PM_DEVFREQ, as illustrated in size-constrained scenarios discussed in Section 4.5, where the objective changes to achieving compact, yet effective kernel configurations.

## 4.5 Optimization

Optimization in software systems entails identifying configurations that best satisfy predefined objectives, such as minimizing resource usage or maximizing efficiency. This endeavor holds practical significance across engineering domains, where the need to balance

<footnote n="1">1. from sklearn.ensemble import RandomForestRegressor</footnote>

<footnote n="2">2. fromsklearn feature selection import SelectFromModel</footnote>

<footnote n="3">3. fromsklearn.model_selectionimport train_test_split</footnote>

<footnote n="4">4. import openml</footnote>
performance constraints against system requirements drives in-
novation [7]. Literature has framed it as a search problem within
expansive configuration landscapes, where exhaustive enumera-
tion falters due to combinatorial growth [6, 20]. Acher et al. [6]
suggest that predictive models can inform this process by high-
lighting factors tied to specific outcomes, although success depends
on navigating trade-offs and interdependencies effectively [5]. The
task takes a configuration dataset as input and aims to deliver an
optimal configuration as output, often measured by the degree to
which it meets the target criterion, such as a minimal value for a
given metric.

In the domain of configurable systems, optimization focuses on
tailoring software to meet precise goals, considering the multitude
of available options and their intricate relationships. For the Linux
kernel, with its thousands of configuration choices, this translates
to crafting setups that excel in diverse aspects—ranging from binary
size and compilation speed to operational robustness [21]. Unlike
earlier tasks that predict or interpret outcomes (Sections 4.1–4.3),
optimization seeks actionable solutions, leveraging insights into
influential factors to guide the search process [6]. The complexity
arises from the sheer scale of possibilities, where dependencies
among options can obscure straightforward paths to an ideal con-
figuration.

Within the *TuxKConfig* dataset, covering seven kernel versions, optimization narrows to minimizing the vmlinux binary size—a critical goal for resource-constrained environments. Here, the input comprises detailed configuration records with associated size measurements, and the output is a single configuration that produces the smallest size, assessed directly by its binary size in MB (e.g., approaching the 7.3 MB of *tinyconfig*, a known minimal benchmark) [34]. Building on the reduced feature sets identified in Section 4.4, this task could employ techniques such as genetic algorithms or gradient-based searches to pinpoint such a configuration, as suggested by the emphasis [6] on size-influencing options [5, 6]. While practical implementations might reveal a kernel under 10 MB, the dataset’s extensive coverage supports exploring trade-offs—say, between size and compilation time—laying a foundation for tailoring kernels to specific performance ranges, as pursued in Section 4.1.

## 4.6 Performance Specialization

Performance specialization in software systems entails identifying
configurations that satisfy specific performance thresholds, such as
a predefined range of resource use or operational efficiency. This
task is crucial in those situations where systems must meet exacting
constraints beyond general optimization [20]. Research positions
it as a constrained search within intricate configuration domains,
employing methods such as restricted exploration or reinforcement
learning to balance diverse factors against set targets [6, 20]. Martin
et al. [20] affirm its practicality, showing that such approaches can
isolate configurations within the desired bounds, although complex-
ity persists in expansive spaces. The process uses a configuration
dataset as input to yield configurations that meet the target range,
evaluated by their adherence to the specified limits.

In configurable systems such as the Linux kernel, with its numer-
ous configuration possibilities, performance specialization targets

set-up within defined intervals, covering binary size, compilation
efficiency, or runtime stability [21]. Unlike optimization's mini-
mization goal (Section 4.5), it seeks a spectrum, such as a 20 to 50
MB kernel size for an IoT device [20]. The dependencies between
options can push configurations beyond the desired range, posing
a key challenge [20].

The *TuxKConfig* dataset supports this task by providing config-
uration records and size data to identify vmlinux sizes within a
predefined range—e.g., 20 to 50 MB. The input comprises configura-
tion details, and the output is a subset that fits the interval, evaluated
by binary size in MB. Extending Section 4.5’s minimal-size focus,
techniques like constrained search could pinpoint such configura-
tions [20], setting the stage for integrating multiple objectives as
described in Section 4.7.

## 4.7 Hybrid Scenarios

Hybrid scenarios in configurable systems involve combining differ-
ent tasks or techniques to address complex and nuanced challenges
more effectively. Instead of treating tasks such as performance pre-
diction (Section 4.1), transfer learning (Section 4.2), interpretability
(Section 4.3), feature selection (Section 4.4), or optimization (Sec-
tion 4.5) in isolation, researchers can integrate them to achieve more
cost-effective outcomes. For instance, feature selection (Section 4.4)
can be paired with interpretability (Section 4.3) to focus on the most
influential configuration options while reducing dimensionality,
with the hope of improving accuracy in performance prediction
(Section 4.1). Similarly, combining interpretability or feature reduc-
tion with transfer learning (Section 4.2) can potentially enhance
inter-version adaptability by selecting stable, meaningful features.
In optimization tasks (Section 4.5), leveraging interpretability in-
sights can guide search strategies.

The Linux kernel, with its vast and evolving configuration space, is an interesting subject for such hybrid approaches since building and measuring configurations is very costly. For example, one might reduce features in version 4.13 using interpretability techniques, then transfer this knowledge to version 5.8—though this raises challenges such as preserving critical dependencies across versions [20]. Extending the constrained focus of performance specialization (Section 4.6), the *TuxKConfig* dataset enables testing these integrated techniques at scale [6], laying the groundwork for the development of practical tools in Section 4.8.

## 4.8 Building Tools out of the Dataset

A variety of practical tooling for developers, researchers, and main-
tainers working with the Linux kernel can be envisioned on top of
*TuxKConfig*. For instance, the dataset can support the development
of improved documentation and exploration tools for Kconfig op-
tions. Currently, documentation is often sparse and rarely details
the impact of configuration options — especially in terms of binary
size. When such information is provided, it is typically approxi-
mate and not consistently updated across kernel versions [5, 29].
Tools that visualize the effect of options on binary size, identify
frequently co-occurring options, or track how options evolve across
versions would be highly valuable. These capabilities could help
both newcomers and experienced developers better navigate the
vast configuration space, revealing hidden dependencies and depre-
cated features.

In addition, *TuxKConfig* can enable configuration automation
through recommendation systems and optimization assistants. A
recommender trained on historical configurations could suggest
sensible defaults based on common usage patterns or previously
successful builds. Similarly, tuners could leverage the dataset to
propose optimized configurations tailored for size, performance, or
other constraints. Finally, predictive models trained on the dataset –
for example, to estimate binary size – could support more informed
configuration workflows and fully taking advantage of the Linux
kernel’s configurability.

## 4.9 Interests for the Machine Learning Community

Tabular data remains a critical frontier for ML, where regression and classification tasks test resilience against real-world complexity [15]. Research underscores the persistent edge of tree-based models over deep learning in such contexts, driven by data sets with high count of features and intricate patterns [6, 32]. Varoquaux et al. [15] argue that tabular datasets, unlike simples benchmarks like Iris with its four features, challenge ML methods with scale and heterogeneity, pushing the boundaries of generalization and efficiency [15, 20]. This intersection of data characteristics and algorithmic demands offers fertile ground for advancing ML methods.

In configurable systems, these challenges amplify as numerous
options and their dependencies shape performance outcomes. For
the Linux kernel, with its hundreds of configuration choices, the
*TuxKConfig* dataset provides a tabular resource spanning 243,232
instances in seven versions, capturing binary size and compilation
times for x86_64 [6]. With a feature dimensionality far exceeding
that of typical tabular datasets, it probes the capacity of methods
like gradient boosting or deep learning to address high-dimensional
regression, aligning with concerns raised in Varoquaux et al. [15]'s
analysis of tabular data limitations. Beyond software engineering
tasks (Sections 4.1–4.7), it enables ML researchers to probe algorithm-
mic scalability and robustness, bridging domain-specific analysis
with broader methodological innovation for practical tool develop-
ment (Section 4.8).

5 Related Work

In addition to Linux, several datasets have been established for performance prediction and optimization in configurable systems [8, 9, 13, 18, 24, 25, 27, 33, 37, 40]. Systems like Apache HTTP Server [35], x264 [26], SQLite [17] and Berkeley DB [35] have been extensively used to evaluate ML techniques across diverse configuration spaces. These benchmarks often provide sampled measurements of performance metrics (e.g., execution time, throughput) across hundreds of configurations. Similarly, systems such as SPEAR [17], SaC [17], and ExaStencils [30] support high-dimensional exploration of configuration landscapes and serve as testbeds for deep learning or surrogate-assisted optimization methods.

In addition to performance-focused datasets, feature model repos-
itories such as SPLOT [31] and the recent UVL corpus [38] offer
structural insights into variability in domains such as automotive,
embedded systems and IoT. These collections are widely used for

benchmarking variability analysis (e.g., with satisfiability solvers). Moreover, configurable systems like MySQL [10, 16] have been used to build datasets of failure-inducing configurations, supporting fault localization and test prioritization tasks. Abal et al. [1, 2] introduce the Variability Bugs Database (VBDb), a benchmark designed to document and analyze real-world variability bugs—such as feature interaction issues—in highly configurable systems, with a focus on the Linux kernel and other large-scale software.

Numerous works study Linux and its huge configuration space [11, 12, 19, 23, 28, 39, 42]. Previous efforts on Linux kernel data include the compilation of over 95,000 configurations for version 4.13 by Acher et al. [3], which focused on predicting binary size, and Melo et al.'s collection of 21,000 configurations [22] for analyzing compilation warnings in a single version. In contrast, our dataset spans multiple kernel versions (4.13 to 5.8), capturing the evolutionary dynamics of configuration options over time. Studies like Passos et al. [29] investigated feature model evolution but lacked performance metrics, while Sharifdeen et al. [36] explored software reuse without a specific focus on Linux. Broader ML research, such as that of Martin et al. [21], has utilized similar datasets for transfer learning applications. However, our work uniquely addresses heterogeneous variability across both space and time (version changes) dimensions. Existing works mainly consider transfer learning with the same feature set (e.g., [8, 17]. Beyond transfer learning, several use-cases over our dataset can be considered (e.g., feature selection, interpretability) to assess or devise AI-based techniques.

To the best of our knowledge, *TuxKConfig* is the largest existing
curated dataset of configurable systems, not limited to the Linux
kernel. Spanning seven kernel versions (4.13 to 5.8), involving 10K+
features, and covering over 200K+ configurations, it exceeds the
scale of prior datasets that typically focus on a single version or
system. As we have described, our dataset calls to investigating
whether AI-based techniques can effectively scale to address key
challenges in software configurable systems, including performance
prediction, optimization, specialization, transfer learning, and in-
terpretability.

6 Conclusion

In this paper, we introduced *TuxKConfig* a large dataset of 243,861 Linux kernel configurations across 7 versions from 4.13 to 5.8, spanning three years of evolution. The dataset uniquely tracks the evolving configuration space with build outcomes and binary sizes. As described, it is suitable for research in various tasks (e.g., performance prediction, transfer learning, identification of influential configuration options) that typically involve the use of AI techniques (e.g., supervised machine learning, sampling strategies). The overall challenge is to find cost-effective solutions capable of accurately predicting and inferring insights out of the huge configuration space of the Linux kernel. We have made an effort to make the dataset available in OpenML and showcase how to use it in a few lines of Python. Beyond the software engineering community, we believe *TuxKConfig* is of interest for researchers interested in tabular data – the scale of our dataset as well as the evolution of the feature set is unique and thus challenging.

Our future work plan is to expand *TuxKConfig* further with
more versions and on other architectures, hopefully delivering a
growing dataset over time for the Linux research community. We also plan to reproduce existing works in the software engineering and AI community using our dataset, leading to a leaderboard and actionable picture of the effectiveness of state-of-the-art solutions with regard to various tasks.

## Acknowledgements

This research was partially funded by the Brazilian funding agencies CAPES (Grant 88881.879016/2023-01), FAPESP (Grant 2023/00811-0) and the Binational Cooperation Program CAPES/COFECUB (Ma1036/24). We also acknowledge the Brazilian company Stone for the financial support.

## References

[1] Iago Abal, Claus Brabrand, and Andrzej Wasowski. 2014. 42 Variability Bugs in the Linux Kernel: A Qualitative Analysis. In *Proceedings of the 29th IEEE/ACM International Conference on Automated Software Engineering (ASE)*. ACM, 421–432. https://doi.org/10.1145/2642937.2642982

[2] Iago Abal, Jean Melo, Stefan StanciuScles, Claus Brabrand, Márcio Ribeiro, and Andrzej Wasowski. 2018. Variability Bugs in Highly Configurable Systems: A Qualitative Analysis. *ACM Transactions on Software Engineering and Methodology (TOSEM)* 26, 3 (2018), 10:1–10:34. https://doi.org/10.1145/3139250

[3] M. Acher et al. 2019. Replication Package for Transfer Learning Study. Zenodo, https://zenodo.org/record/4960172.

[4] Mathieu Acher, Hugo Martin, Juliana Alves Pereira, Arnaud Blouin, Djamel Eddine Khelladi, and Jean-Marc Jézéquel. 2019. *Learning From Thousands of Build Failures of Linux Kernel Configurations*. Technical Report. Inria IRISA. 1–12 pages. https://inria.hal.science/hal-02147012

[5] Mathieu Acher, Hugo Martin, Luc Lesoil, Arnaud Blouin, Jean-Marc Jézéquel, Djamel Eddine Khelladi, Olivier Barais, and Juliana Alves Pereira. 2022. Feature subset selection for learning huge configuration spaces: the case of linux kernel size. In *Proceedings of the 26th ACM International Systems and Software Product Line Conference - Volume A (SPLC '22)*. ACM, 85–96. https://doi.org/10.1145/3546932.3546997

[6] Mathieu Acher, Hugo Martin, Juliana Alves Pereira, Arnaud Blouin, Jean-Marc Jézéquel, Djamel Eddine Khelladi, Luc Lesoil, and Olivier Barais. 2019. *Learning Very Large Configuration Spaces: What Matters for Linux Kernel Sizes*. Research Report. Inria Rennes - Bretagne Atlantique. https://inria.hal.science/hal-02314830

[7] Juliana Alves Pereira, Mathieu Acher, Hugo Martin, and Jean-Marc Jézéquel. 2020. Sampling Effect on Performance Prediction of Configurable Systems: A Case Study. In *Proceedings of the ACM/SPEC International Conference on Performance Engineering (ICPE '20)*. ACM, 277–288. https://doi.org/10.1145/3358960.3379137

[8] Juliana Alves Pereira, Hugo Martin, Mathieu Acher, Jean-Marc Jézéquel, Goetz Botterweck, and Anthony Ventresque. 2021. Learning Software Configuration Spaces: A Systematic Literature Review. *Journal of Systems and Software* (Aug. 2021). https://doi.org/10.1016/j.jss.2021.111044

[9] João Marcello Bessa, Millena Cavalcanti, Mathieu Acher, Markus Endler, and Juliana Alves Pereira. 2025. Unveiling the Impact of Sampling on Feature Selection for Performance Prediction in Configurable Systems. In *Proceedings of the International Conference on Systems and Software Reuse (ICSR '25)*. IEEE, 1–12.

[10] Casey Eddington, Myra Cohen, and Wolfram Schulte. 2018. Automatically Detecting Feature Interactions Using Priorities and Data Dependencies. In *Proc. Int. Conf. Software Engineering (ICSE)*. 105–116. https://doi.org/10.1145/3180155.3180177

[11] David Fernández-Amorós, Ruben Heradio, José Miguel Horcas Aguilara, José A. Galindo, David Benavides, and Lidia Fuentes. 2024. Pragmatic Random Sampling of the Linux Kernel: Enhancing the Randomness and Correctness of the conf Tool. In *Proceedings of the 28th ACM International Systems and Software Product Line Conference - Volume A, SPLC 2024, Dommeldange, Luxembourg, September 2-6, 2024*, Maxime Cordy, Daniel Strüber, Mónica Pinto, Iris Groher, Deepak Dhungana, Jacob Krüger, Juliana Alves Pereira, Mathieu Acher, Thomas Thüm, Maurice H. ter Beek, Jessie Galasso-Carbonnel, Paolo Arcaini, Mohammad Reza Mousavi, Xhevahire Tërnava, José A. Galindo, Tao Yue, Lidia Fuentes, and José Miguel Horcas (Eds.). ACM, 24–35. https://doi.org/10.1145/3646548.3672586

[12] Patrick Franz, Thorsten Berger, Ibrahim Fayaz, Sarah Nadi, and Evgeny Groshev. 2021. ConfigFix: Interactive Configuration Conflict Resolution for the Linux Kernel. In *43rd IEEE/ACM International Conference on Software Engineering: Software Engineering in Practice, ICSE (SEIP) 2021, Madrid, Spain, May 25-28, 2021*. IEEE, 91–100. https://doi.org/10.1109/ICSE-SEIP52600.2021.00018

[13] Wei Fu and Tim Menzies. 2017. Easy over Hard: A Case Study on Deep Learning. In *Proc. of ESEC-FSE'17*. 49–60. https://doi.org/10.1145/3106237.3106256

[14] Léo Grinsztajn, Edouard Oyallon, and Gaël Varoquaux. 2022. Why do tree-based models still outperform deep learning on typical tabular data?. In *Proceedings of the 36th International Conference on Neural Information Processing Systems (New Orleans, LA, USA) (NIPS '22)*. Curran Associates Inc., Red Hook, NY, USA, Article 37, 14 pages.

[15] Léo Grinsztajn, Edouard Oyallon, and Gaël Varoquaux. 2022. Why do tree-based models still outperform deep learning on typical tabular data? *Advances in neural information processing systems* 35 (2022), 507–520. https://doi.org/10.1109/ICST.2016.32

[16] Qingzhou Huang, Myra Cohen, and Wolfram Schulte. 2016. Testing Configurable Systems with Rule-Based Specifications. In *Proc. Int. Conf. Software Testing, Verification and Validation (ICST)*. 177–187. https://doi.org/10.1109/ICST.2016.32

[17] Pooyan Jamshidi, Norbert Siegmund, Miguel Velez, Christian Kästner, and Yuvraj Agarwal. 2017. Transfer Learning for Performance Modeling of Configurable Systems: An Exploratory Analysis. In *Proc. Int. Conf. Software Engineering (ICSE)*. 812–823. https://doi.org/10.1109/ICSE.2017.79

[18] Pooyan Jamshidi, Miguel Velez, Christian Kästner, and Norbert Siegmund. 2018. Learning to sample: exploiting similarities across environments to learn performance models for configurable systems. In *Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering*. 71–82.

[19] Elias Kuiter, Chico Sundermann, Thomas Thüm, Tobias Hess, Sebastian Krieter, and Gunter Saake. 2025. How Configurable is the Linux Kernel? Analyzing Two Decades of Feature-Model History. *ACM Trans. Softw. Eng. Methodol.* (April 2025). https://doi.org/10.1145/3729423 Just Accepted.

[20] Hugo Martin, Mathieu Acher, Juliana Alves Pereira, and Jean-Marc Jézéquel. 2021. A comparison of performance specialization learning for configurable systems. In *Proceedings of the 25th ACM International Systems and Software Product Line Conference - Volume A (Leicester, United Kingdom) (SPLC '21)*. Association for Computing Machinery, New York, NY, USA, 46–57. https://doi.org/10.1145/3461001.3471155

[21] Hugo Martin, Mathieu Acher, Juliana Alves Pereira, Luc Lesoil, Jean-Marc Jézéquel, and Djamel Eddine Khelladi. 2021. Transfer Learning Across Variants and Versions: The Case of Linux Kernel Size. *IEEE Transactions on Software Engineering* 48, 11 (2021), 4274–4290.

[22] J. Melo et al. 2016. Analyzing Configuration-Dependent Warnings in Linux. In *Proc. SPLC*.

[23] Johann Mortara and Philippe Collet. 2021. Capturing the diversity of analyses on the Linux kernel variability. In *SPLC '21: 25th ACM International Systems and Software Product Line Conference, Leicester, United Kingdom, September 6-11, 2021, Volume A, Mohammad Reza Mousavi and Pierre-Yves Schobbens* (Eds.). ACM, 160–171. https://doi.org/10.1145/3461001.3471151

[24] Vivek Nair, Rahul Krishna, Tim Menzies, and Pooyan Jamshidi. 2018. Transfer Learning with Bellwethers to find Good Configurations. *CoRR* abs/1803.03900 (2018). arXiv:1803.03900 http://arxiv.org/abs/1803.03900

[25] Vivek Nair, Tim Menzies, Norbert Siegmund, and Sven Apel. 2017. Using bad learners to find good configurations. In *Proc. of ESEC/FSE'17*. 257–267.

[26] Vivek Nair, Norbert Siegmund, Tim Menzies, and Sven Apel. 2020. Using Bad Learners to Find Good Configurations. *IEEE Transactions on Software Engineering* 46, 4 (2020), 410–428. https://doi.org/10.1109/TSE.2018.2875384

[27] Jeho Oh, Don Batory, Margaret Myers, and Norbert Siegmund. 2017. Finding Near-Optimal Configurations in Product Lines by Random Sampling. In *Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (Paderborn, Germany) (ESEC/FSE 2017)*. Association for Computing Machinery, New York, NY, USA, 61–71. https://doi.org/10.1145/3106237.3106273

[28] Jeho Oh, Necip Fazil Yildiran, Julian Braha, and Paul Gazzillo. 2021. Finding broken Linux configuration specifications by statically analyzing the Kconfig language. In *ESEC/FSE '21: 29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, Athens, Greece, August 23-28, 2021*, Diomidis Spinellis, Georgios Gousios, Marsha Chechik, and Massimiliano Di Penta (Eds.). ACM, 893–905. https://doi.org/10.1145/3468264.3468578

[29] L. Passos et al. 2018. Feature Model Evolution in Linux. *IEEE Software* 35, 4 (2018), 45–52.

[30] Chen Peng, Yao Li, Lin Yuan, Yuwei Lin, and Yijun Yu. 2021. VEER: Black-box Performance Configuration Optimization for Cloud Applications. In *Proc. Int. Symp. Software Engineering for Adaptive and Self-Managing Systems (SEAMS)*. 81–92. https://doi.org/10.1109/SEAMS51251.2021.00018

[31] Juliana Alves Pereira, Kattiana Constantino, and Eduardo Figueiredo. 2014. A systematic literature review of software product line management tools. In *Proceedings of the International Conference on Systems and Software Reuse (ICSR '14)*. Springer, 73–89.

[32] Juliana Alves Pereira, Hugo Martin, Paul Temple, and Mathieu Acher. 2020. Machine learning and configurable systems: a gentle introduction. In *Proceedings of the 24th ACM Conference on Systems and Software Product Line: Volume A - Volume A (Montreal, Quebec, Canada) (SPLC '20)*. Association for Computing Machinery, New York, NY, USA, Article 40, 1 pages. https://doi.org/10.1145/3382025.3414976

[33] Clément Quinton, Michael Vierhauser, Rick Rabiser, Luciano Baresi, Paul Grünbacher, and Christian Schuhmayer. 2020. Evolution in dynamic software product lines. *Journal of Software: Evolution and Process (2020)*, e2293.
[34] Georges Aaron Randrianaina, Djamel Eddine Khelladi, Olivier Zendra, and Mathieu Acher. 2022. Towards incremental build of software configurations. In *Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: New Ideas and Emerging Results* (Pittsburgh, Pennsylvania) (ICSE-NIER '22). Association for Computing Machinery, New York, NY, USA, 101–105. https://doi.org/10.1145/3510455.3512792

[35] Anurag Sarkar, Norbert Siegmund, Saeedeh Shekarpour, and Sven Apel. 2015. Efficient Performance Prediction for Configurable Software: The Case of Database Management Systems. In *Proc. Int. Conf. Automated Software Engineering (ASE)*. 91–102. https://doi.org/10.1109/ASE.2015.31

[36] R. Shariffdeen. 2024. Exploring Software Reuse Patterns. https://rshariffdeen.com/paper/MSR24.pdf.

[37] Norbert Siegmund, Alexander Grebhahn, Sven Apel, and Christian Kästner. 2015. Performance-influence models for highly configurable systems. In *Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2015, Bergamo, Italy, August 30 - September 4, 2015*, Elisabetta Di Nitto, Mark Harman, and Patrick Heymans (Eds.). ACM, 284–294. https://doi.org/10.1145/2786805.2786845

[38] Christoph Sundermann, Nico Puhlmann, Janet Siegmund, Max Leuthäusser, and Thomas Thüm. 2024. A Benchmark of Feature Models in the UVL Format. In

*Proc. Int. Conf. Systems and Software Product Line Conf. (SPLC)*. https://github.com/FeatureIDE/uvl-benchmark To appear.

[39] Reinhard Tartler, Daniel Lohmann, Julio Sincero, and Wolfgang Schröder-Preikschat. 2011. Feature consistency in compile-time-configurable system software: facing the linux 10,000 feature problem. In *Proceedings of the Sixth Conference on Computer Systems (Salzburg, Austria) (EuroSys '11)*. Association for Computing Machinery, New York, NY, USA, 47–60. https://doi.org/10.1145/1966445.1966451

[40] Pavel Valov, Jean-Christophe Petkovich, Jianmei Guo, Sebastian Fischmeister, and Krzysztof Czarnecki. 2017. Transferring Performance Prediction Models Across Different Hardware Platforms. In *Proceedings of the 8th ACM/SPEC on International Conference on Performance Engineering*. Association for Computing Machinery, New York, NY, USA, 39–50. https://doi.org/10.1145/3030207.3030216

[41] Joaquin Vanschoren, Jan N. van Rijn, Bernd Bischl, and Luis Torgo. 2013. OpenML: Networked Science in Machine Learning. *SIGKDD Explorations* 15, 2 (2013), 49–60. https://doi.org/10.1145/2641190.2641198

[42] Necip Fazil Yildiran, Jeho Oh, Julia Lawall, and Paul Gazzillo. 2024. Maximizing Patch Coverage for Testing of Highly-Configurable Software without Exploding Build Times. *Proc. ACM Softw. Eng.* 1, FSE (2024), 427–449. https://doi.org/10.1145/3643746