Greedy-Balancing Algorithm (Octopus)

• Greedy-Balancing is a lightweight heuristic that proportionally allocates resources among hosts and pools to prevent premature depletion and maintain balance.
• In CXL memory pooling, it distributes a host's demand based on available pool capacity, ensuring full demand satisfaction while preserving near-equal residual capacities.
• In crowdsourcing, it drives task assignment and dynamic pay-setting with greedy one-step lookahead, achieving up to 37% higher utility over traditional methods.

The Greedy-Balancing algorithm appears in two distinct domains under the Octopus framework: CXL memory pooling systems for distributed computing and advanced hierarchical control in crowdsourcing marketplaces. In both contexts, Greedy-Balancing denotes a class of lightweight heuristics or controllers that allocate resources among competing agents so as to avoid premature depletion, maintain balance on shared bottlenecks, and efficiently accommodate system constraints. The algorithm is defined by its local, proportional, and greedy assignment policies, and by its empirical sufficiency in complex, large-scale infrastructure. The following sections systematically cover the formulation, design principles, theoretical properties, and practical significance of Greedy-Balancing in both memory systems and crowdsourcing optimization.

1. Problem Formulations in Octopus Systems

Memory Pooling Context

Within CXL-enabled compute “pods,” the Octopus model formalizes the allocation problem as a bipartite graph $G = (H \cup P, E)$, where $H$ is a set of hosts, $P$ is a set of multi-headed DRAM pool devices, and $E$ encodes host-pool connectivity via CXL links. Each host $h \in H$ has fixed degree $X$ (i.e., CXL ports to $X$ pools), while each pool $p \in P$ serves $N$ hosts and exposes finite capacity $C_p$. Each host $H$0 demands memory $H$1, to be split among its neighbor pools $H$2. The allocation constraints are:

• $H$3 for all $H$4 (full demand satisfaction)
• $H$5 for all $H$6 (pool capacity constraints)

This setting departs from classical, fully symmetric topologies (where every host is adjacent to every pool) and requires non-uniform, adaptive allocation policies to maintain fairness and avoid deadlock due to partial pool exhaustion (Berger et al., 15 Jan 2025).

Crowdsourcing Context

In large-scale microtask crowdsourcing, the Octopus framework must balance three objectives for a batch of $H$7 binary classification tasks: quality (accuracy of final answers), cost (monetary expenditure for worker ballots), and time (wall-clock duration). The additive system utility is:

$H$8

where $H$9 is the expected reward for task $P$0 (discounted for confidence penalties) and $P$1 is the cost spent on $P$2. The state for the top-level controller collapses to two aggregate statistics $P$3, where $P$4 is batch-normalized confidence and $P$5 is expected remaining ballots, plus current time $P$6 and pay-rate $P$7 (Goel et al., 2017).

2. Formal Definition and Pseudocode

Memory Pool Greedy-Balancing Algorithm

For a single host $P$8 with demand $P$9, the Greedy-Balancing routine operates as follows:

1. For the set of pools $E$0, retrieve remaining capacities $E$1 for all $E$2.
2. Let $E$3.
3. If $E$4, allocation is infeasible ("insufficient reachable capacity").
4. For each $E$5, assign:

$E$6

and update $E$7.

1. Return the allocation vector $E$8.

This ensures $E$9 for all $h \in H$0, full demand satisfaction per host, and capacity constraints are never violated locally. The allocation is greedily spread in proportion to current free capacity (Berger et al., 15 Jan 2025).

Crowdsourcing Greedy-Balancing Controller

In the three-layer Octopus controller:

• QualityManagers: Model each task as a POMDP, solved off-line for each possible pay level $h \in H$1 using value iteration. At runtime, each QM can greedy-select “get another ballot” or “terminate” based on current belief state.
• TaskSelector: When a new worker arrives, select the incomplete task $h \in H$2, where

$h \in H$3

and $h \in H$4 is task $h \in H$5's expected utility after one further ballot (greedy one-step lookahead).

• CostSetter: At regular intervals, choose a pay adjustment or termination by maximizing expected aggregated utility using an MDP solved over the reduced state $h \in H$6. The system evolves via greedy, tractable actions at each stage (Goel et al., 2017).

3. Theoretical Properties and Performance Guarantees

Complexity and Correctness (Memory Pooling)

• Time complexity: $h \in H$7 per host allocation, where $h \in H$8 is the number of neighboring pools per host. For $h \in H$9 allocations: $X$0.
• Space complexity: $X$1 for the bipartite adjacency, $X$2 for demand and remaining capacity arrays.
• Correctness: At each step, allocations are non-negative, satisfy per-host demand, and never exceed available pool capacity.
• Balancing guarantee: Immediately after allocation to host $X$3, among the pools $X$4, the ratio of maximum to minimum residual capacities is at most $X$5. Hence, if $X$6, the pool availabilities remain nearly balanced, limiting risk that any one pool is prematurely exhausted (Berger et al., 15 Jan 2025).

Tractability and Empirical Sufficiency (Crowdsourcing)

• Greedy architecture: The full joint MDP/POMDP over all tasks, time, and cost is intractable; Octopus compresses to two aggregate values, uses greedy one-step routing, and solves small MDPs for pay-setting. This yields a real-time, computationally efficient controller (Goel et al., 2017).
• Empirical results: Achieves up to 37% higher utility than two-objective reinforced baselines in both simulation and live Mechanical Turk deployments, despite lack of formal global optimality or error bounds (Goel et al., 2017).

4. Empirical Evaluation and Observed Behavior

CXL Memory Pooling

• Cost and latency: Octopus pods with small 4-port multi-headed devices (MHDs) achieve $X$7 lower silicon cost per host and $X$8 ns latency, compared to $X$9 ns for larger 8-port MHDs (see Table 2 in (Berger et al., 15 Jan 2025)).
• Algorithmic sufficiency: The Greedy-Balancing algorithm, while not directly benchmarked against alternatives, is described as maintaining balanced bandwidth and preventing dead (starved) hosts in microbenchmarks. Shuffle communication workloads can exploit structural topology guarantees for direct pool placement, bypassing further balancing (Berger et al., 15 Jan 2025).

Crowdsourcing

• Practicality: The greedy one-step controllers are tractable for large task batches. Pay-setting adapts to market feedback within a small MDP, and task assignment ensures ballots are routed to maximize expected utility improvement (Goel et al., 2017).
• Sufficiency: Empirical studies show strong performance relative to methods that optimize only cost-quality or cost-time, across both simulated and live data (Goel et al., 2017).

5. Insights, Limitations, and Parameter Tuning

Memory Pooling

• For $X$0 in the range $X$1–$X$2, execution overhead is negligible (a few microseconds per 1 GB allocation), and deployments require no dynamic reconfiguration of CXL fabric.
• Extensions for hosts with atypical bandwidth demands are straightforward: allocations can be biased towards higher-capacity pools, provided constraints are maintained.
• In regular Octopus topologies, shared communication patterns can pin allocations to dedicated common pools (Berger et al., 15 Jan 2025).
• A plausible implication is that tighter theoretical bounds or comparative algorithmic analyses may require network flow or matching formalism, but these are not developed in the current literature.

Crowdsourcing

• By eschewing the intractable full joint model for greedy/hierarchical allocation, the Octopus framework achieves real-time control suitable for actual production marketplaces.
• The use of $X$3-reconstruction and aggressive state compression ensures scalability while maintaining sufficient batch-level dynamism (Goel et al., 2017).
• No explicit error bounds or global optimality guarantees are provided, but empirical results substantiate the sufficiency of Greedy-Balancing in practice, especially when worker arrivals and task difficulties are highly variable.

6. Related Techniques and Open Directions

Both memory and crowdsourcing domains leverage local greedy allocation on bottleneck resources. The key shared principles are:

• Allocation in direct proportion to measured or estimated slack/resource, avoiding over-depletion.
• Greedy one-step approximations to otherwise intractable global optimization, with empirical validation standing in for theoretical guarantees.
• Use of hierarchical, modular control to separate fast local resource balancing from slower, batch-level adjustment or pay-setting.

This suggests interesting future work in extending Greedy-Balancing to settings with adversarial demand patterns, dynamic or stochastic pool failures, or more granular utility-cost trade-offs. Formal approximation ratios and competitive analyses remain to be established for generalized, irregular topologies.

7. Summary Table: Greedy-Balancing in Octopus Systems

Domain	Resource	Objective(s)	Greedy-Balancing Role
CXL Memory Pool	DRAM on pools	Satisfy host demands, usage balance	Splits host demand across reachable pools by proportional available capacity, per host request
Crowdsourcing	Worker ballots, pay	Maximize utility (quality, cost, time)	Greedy one-step routing for task assignment, per-batch pay-setting, state compression

Both applications demonstrate the feasibility and sufficiency of Greedy-Balancing as a principled, practical allocation heuristic in distributed, resource-constrained systems, despite the lack of comprehensive theoretical guarantees (Berger et al., 15 Jan 2025, Goel et al., 2017).