IG-GPU: Integrated GPU Discovery in ARC

• IG-GPU is an integrated GPU discovery mechanism in ARC that harvests SLURM GRES strings and publishes them as GLUE2 XML, enabling visibility of GPU resources.
• It supports high-energy physics workflows such as track fitting and Monte Carlo simulation by aggregating heterogeneous GPU partitions without detailed accelerator attributes.
• Validated on clusters with NVIDIA Tesla GPUs, IG-GPU highlights infrastructural challenges and points to future work on richer metadata and cross-LRMS support.

Searching arXiv for papers using or contextualizing the term "IG-GPU". IG-GPU most commonly denotes the integrated GPU discovery mechanism added to ARC (Advanced Resource Connector) Information Providers so that GPU-related SLURM Generic Resources (GRES) become visible in ARC’s GLUE 2 XML and client tooling, especially for High-energy Physics workflows such as track fitting, particle reconstruction, and Monte Carlo simulation (Isacson et al., 2019). In practice, the same string has also been used in unrelated GPU literatures, including a PyTorch re-architecture of Interpretable Generalization for cyberattack detection, an informal alias for the interaction-net evaluator ingpu, and discussions of integrated GPU systems in security research (Huang et al., 16 Jul 2025). This suggests that “IG-GPU” is best interpreted only in conjunction with its surrounding domain and cited source.

1. Terminological scope

The ARC usage is the clearest formally specified meaning: an implementation that discovers GPU resources from SLURM and publishes them through ARC’s information system (Isacson et al., 2019). Other papers show that the string is not globally reserved.

Context	Meaning	Representative source
ARC grid middleware	Integrated GPU discovery in ARC Information Providers	(Isacson et al., 2019)
Intrusion detection	PyTorch GPU re-architecture of Interpretable Generalization	(Huang et al., 16 Jul 2025)
Interaction nets	ingpu; “IG-GPU” is best understood as an informal alias	(Jiresch, 2014)
Integrated CPU–GPU systems	iGPU context in cross-component covert channels	(Dutta et al., 2020)

In adjacent literature, similar acronyms reinforce the ambiguity. “G-GPU” denotes a general-purpose GPU-like accelerator generated by GPUPlanner rather than ARC middleware (Perez et al., 2021), while “IrGL” denotes an explicitly parallel IR for irregular GPU programs that is lowered to CUDA by the Galois GPU compiler (Pai et al., 2016). A plausible implication is that, in technical writing, the term should be disambiguated immediately by paper title or subsystem name.

2. ARC motivation and middleware setting

Within ARC, IG-GPU was introduced to lower the barrier to GPGPU use in grid environments that had remained mainly centred around traditional CPU resources (Isacson et al., 2019). The motivating workloads are compute-bound HEP tasks that are naturally parallelizable: track fitting and particle reconstruction, as well as Monte Carlo simulation with large numbers of independent events or particles. The stated bottlenecks are analysis turnaround and resource contention on CPU-only grids.

ARC, developed by NorduGrid, aggregates heterogeneous distributed resources into a single virtual GRID site and dispatches jobs to available Compute Elements. Its Information Providers form the discovery path. CEinfo.pl is the entry point that detects the site’s Local Resource Management System flavor and invokes the corresponding LRMS-specific Perl module, such as SLURMmod.pm. These modules query the LRMS, build a resource description, and feed it into ARC’s information model. ARC then converts the queried data into GLUE2-format XML through GLUE2xmlPrinter.pm, which is consumed by users and monitoring tools such as arcinfo and the Web GRID Monitor (Isacson et al., 2019).

In that architecture, IG-GPU is not a separate scheduler or accelerator runtime. It is an information-path extension: GPU-related metadata are harvested from the LRMS, attached to the ARC resource description, serialized into GLUE2 XML, and exposed to clients.

3. Discovery mechanism and data model

The implemented discovery method is LRMS-centric and relies on SLURM’s GRES reporting via sinfo (Isacson et al., 2019). The command used is:

sinfo -a -h -o "gresinfo=%G"

or equivalently:

sinfo -a -h -o "%G"

The observed sample output on Kebnekaise included partition-level strings such as:

(null) gpu:k80ce:4,mps:no_consume:1,gpuexcl:no_consume:1 gpu:k80ce:8,mps:no_consume:1,gpuexcl:no_consume:1 gpu:v100:2,mps:no_consume:1,gpuexcl:no_consume:1 hbm:16G hbm:0

SLURMmod.pm adds slurm_read_gresinfo(), which opens a pipe to sinfo, skips lines matching (null), calls get_variable("gresinfo", $string) for lines with data, and pushes the parsed strings into @sinfo_gresinfo. LRMSInfo.pm extends the cluster schema with a gres field. ARC1ClusterInfo.pm, in collect(), attaches the GRES list to the ComputingManager data as:

%%%%0%%%%cluster_info->{gres};

The collected metadata are exactly the SLURM GRES strings as reported. They include GPU type labels such as gpu:k80ce and gpu:v100, counts such as :4, :8, and :2, additional flags such as mps:no_consume:1 and gpuexcl:no_consume:1, and HBM sizes such as hbm:16G. By design, the mechanism does not collect vendor-specific attributes such as compute capability, SM or CUDA core counts, clock rates, or driver and runtime versions. It also does not publish a per-node inventory; the listing is partition-level and generic rather than host-level (Isacson et al., 2019).

This creates an important interpretive boundary. IG-GPU in ARC is not a hardware probing framework. It republishes scheduler-visible generic resources. Heterogeneous partitions therefore appear as multiple Resource lines rather than as a normalized accelerator inventory.

4. GLUE publication and client consumption

The discovered data are published as GLUE 2 XML by introducing a custom GeneralResources element under ComputingManager (Isacson et al., 2019). The path is:

InfoRoot/Domains/AdminDomain/Services/ComputingService/ComputingManager/GeneralResources/Resource

An example published structure is:

<GeneralResources> <Resource>gpu:k80ce:4,mps:no_consume:1,gpuexcl:no_consume:1</Resource> <Resource>gpu:k80ce:8,mps:no_consume:1,gpuexcl:no_consume:1</Resource> <Resource>gpu:v100:2,mps:no_consume:1,gpuexcl:no_consume:1</Resource> <Resource>hbm:16G</Resource> <Resource>hbm:0</Resource> </GeneralResources>

On the client side, ExecutionTarget.h and ExecutionTarget.cpp add GeneralResources as a list in Arc::ComputingManagerAttributes and print it in arcinfo under a “General resources:” section. GLUE2.cpp parses GeneralResources/Resource nodes and populates the client-side list. End-to-end, the publication and consumption path is therefore:

sinfo output → SLURMmod.pm → LRMSInfo.pm → ARC1ClusterInfo.pm → GLUE2xmlPrinter.pm → arcinfo

A common misconception is to treat this as a standardized accelerator schema. The paper explicitly does not do that. GeneralResources is an extension focused on making GRES visible; it is not a standardized GLUE2 accelerator class field (Isacson et al., 2019). The significance is practical rather than ontological: ARC clients can discover that GPU-related resources exist, but they cannot perform fine-grained matchmaking on detailed accelerator capabilities that were never published.

5. Scheduling, submission, validation, and operations

The job-submission path uses a Runtime Environment rather than native ARC-level GPU matchmaking semantics (Isacson et al., 2019). In the RTE, the environment variable joboption_nodeproperty_# is modified to append a SLURM directive such as:

#SBATCH --gres=gpu:k80:1

A minimal XRSL job specification requests that RTE, and the job is submitted with arcsub. For SLURM, this maps directly to --gres=gpu:<type>:<count>. Other batch systems such as HTCondor and PBS are outside the scope of the implementation.

Because the published data are generic GRES strings, constraints can be expressed only at the level of the GRES label, such as k80ce or v100. Fine-grained constraints like memory per GPU, compute capability, and driver version are not published by the implementation and therefore cannot be used at ARC matchmaking time (Isacson et al., 2019).

Validation was carried out on the Kebnekaise cluster at HPC2N, which had 80 NVIDIA Tesla K80 and 20 NVIDIA Tesla V100 cards. The paper reports successful end-to-end verification through XML output and arcinfo, showing the expected “General resources:” entries. It does not report discovery overhead, throughput gains, utilization metrics, scheduler latency impacts, selection algorithms, or performance equations (Isacson et al., 2019).

Operationally, the prerequisites are straightforward but strict. SLURM GRES must already be configured to publish GPU resources, which can be checked with sinfo -a -h -o "%G". ARC-side enablement requires modified modules across the full chain, including SLURMmod.pm, LRMSInfo.pm, ARC1ClusterInfo.pm, GLUE2xmlPrinter.pm, ExecutionTarget.h, ExecutionTarget.cpp, and GLUE2.cpp. Verification consists of querying the Computing Service endpoint with arcinfo and checking the “General resources:” section. If no GPU entries appear, the paper’s troubleshooting logic is to confirm that sinfo returns non-(null) GPU lines, that the modified modules are deployed, that CEinfo.pl invokes the SLURM provider, and that GLUE2xmlPrinter emits GeneralResources under the ComputingManager node (Isacson et al., 2019).

6. Limitations, future work, and broader meanings

The principal limitation of the ARC implementation is representational depth (Isacson et al., 2019). It introduces a GeneralResources extension rather than populating standardized GPU or accelerator attributes in GLUE2. There is no common schema here for GPU vendor, compute capability, memory per device, or driver and runtime versions. There is also no probing via lspci, nvidia-smi, ROCm, or OpenCL, and no host-level inventory. Multi-tenancy, fairshare, accounting, and security remain the responsibility of the LRMS and site policy; GPU accounting and per-user quotas in ARC are not addressed.

Future work identified in the paper is correspondingly modest and infrastructural. It could include richer metadata publication through vendor tools, mapping those metadata into a community-accepted GLUE schema for accelerators, automatic publication of supported frameworks and versions, and analogous provider-side implementations for LRMS backends beyond SLURM (Isacson et al., 2019). Recommended best practices are to ensure accurate SLURM GRES configuration, deploy the modified ARC modules end to end, provide site-documented RTEs for common GPU types such as k80 and v100, and align software stacks such as CUDA, ROCm, or containers with the site’s GPU hardware and SLURM configuration.

Beyond ARC, the label “IG-GPU” has acquired materially different meanings. In cybersecurity, “IG-GPU” names a PyTorch re-architecture of Interpretable Generalization that offloads pairwise intersections and subset evaluations to a single NVIDIA RTX 4070 Ti, reporting a 116-fold speed-up on the 15k-record NSL-KDD dataset and full-scale NSL-KDD training in 18 minutes 21 seconds with Recall 0.95728, Precision 0.97315, and AUC 0.96093 (Huang et al., 16 Jul 2025). In interaction-net evaluation, the system is actually named ingpu; the data explicitly state that the term “IG-GPU” does not appear in that paper and is best understood as a synonym or informal alias rather than a distinct implementation (Jiresch, 2014). In integrated CPU–GPU security work, “integrated GPU” refers instead to an iGPU on the same die as the CPU, where shared LLC and ring-bus resources enabled covert channels of up to approximately 120 kb/s at approximately 2% error for the LLC-based channel and up to approximately 400 kb/s at approximately 0.8% error for the contention-based channel (Dutta et al., 2020).

Taken together, these usages show that IG-GPU is not a single stable technical object across the arXiv literature. In the strict ARC sense, it is a scheduler-facing GPU discovery and publication mechanism built around SLURM GRES strings and GLUE2 exposure (Isacson et al., 2019). In other domains, it denotes unrelated GPU acceleration strategies or is only an informal shorthand. This suggests that the term functions less as a universal acronym than as a context-dependent label whose meaning is fixed by the cited system.