Dynamic Resource Control

Crafting shares underlying compute resources across multiple workloads from different sandboxes. Because development workloads have highly variable and unpredictable resource usage, the actual resources allocated to each workload are adjusted continuously rather than fixed at a static amount.

Enabling swap on the underlying machines is essential. Without swap, workloads are killed as soon as physical memory reaches pressure.

Memory and Swap

A soft cap on memory and swap is placed on each workload by allocating available node resources weighted by current usage. This soft cap is continuously adjusted as usage changes.

Specifying a Memory Request

A workload can specify a minimum memory reservation via schedule_spec:

workspaces:
- name: dev
  schedule_spec:
    resource_requests:
    - resource_type: memory
      request: 4Gi

The request value is the minimum amount of memory allocated when the workload starts. A higher request gives the workload more memory from the start, but may reduce overall memory utilization on the node if the workload typically uses much less.

Why Lower Memory Requests Often Perform Better

Consider a node with:

• Total allocatable memory: 100 GB
• Swap: 20 GB
• 5 workloads, each with a 16 GB memory request

In this case:

• Shared physical memory: 100 - (16 × 5) = 20 GB
• 4 workloads use ~2 GB each
• 1 workload uses 36 GB physical memory + 18 GB swap
• Physical memory utilization: 44% — but swap is at 90%

This is suboptimal because there is 54 GB of unused physical memory sitting reserved.

If the memory requests are reduced to 4 GB each:

• Shared physical memory: 100 - (4 × 5) = 80 GB
• The high-memory workload gets 54 GB in physical memory with zero swap
• Memory utilization: 62% — all in physical RAM, with no swap pressure

Lower memory requests lead to better overall performance when the actual usage is well below the requested amount, because more physical memory becomes available for workloads that actually need it.

See Also

• Schedule Specification — specifying memory and GPU requests
• Node Pool — node configuration including swap requirements
• System Admin Dashboard — monitoring resource utilization