Skip to content

Track retirement of loader_scratch_vm_allocate.patch (iOS loader scratch stays in the footprint) #45

Closed

Description

@leehack

Problem

On iOS 18, after v0.3.0-5 moved ggml host buffers to vm_allocate (#44), about 240 MiB of an SD-Turbo model's footprint still stays in libmalloc's cache after dispose (llamadart #2004, plan #2011). It is held by the per-thread scratch vectors in ModelLoader::load_tensors (third_party/stable-diffusion.cpp/src/model_loader.cpp, read_buffer, convert_buffer, zip_entry_buffer) and by convert_tensor's buf.

Fix

patches/loader_scratch_vm_allocate.patch backs those buffers with vm_allocate/vm_deallocate on Apple; other platforms keep std::vector. Test: tests/test_loader_scratch_runtime.py.

Patch-specific maintainer exception

Like torch_zip_entry_lookup.patch (#24), no upstream report is filed: the maintainer has not authorized one. This issue tracks retirement until an upstream report is authorized; retire the patch when upstream's loader no longer takes tensor-sized scratch from the heap on Apple platforms.

Acceptance

  • PR adding the patch and test merged.
  • Verified on iOS 18 after a release.
  • Patch retired or an upstream report authorized.

Activity

  1. added
    bugSomething isn't working
    priority:P2Important improvement or regression; schedule next
    blocked-upstreamNeeds an upstream runtime/driver fix or unavailable hardware; not fixable in this repo
    and removed
    blocked-upstreamNeeds an upstream runtime/driver fix or unavailable hardware; not fixable in this repo
    on Nov 14, 2026
  2. leehack commented on Nov 15, 2026

    @leehack
    OwnerAuthor

    Fixed by #46 (merged as 0ec6c1f), which ships in v0.3.0-6. On-device iOS 18 confirmation will come from the llamadart A/B.

    Non-blocking audit P3s, kept here:

    • patches/README.md: the new row (and the earlier intrinsic_tiny_decoder_policy row) comes after a blank line, so GitHub renders it as plain text, not as part of the table.
    • No test catches removing vm_deallocate from TensorScratch::release() (mutation M5), and none proves the memory goes back to the OS. The probe only checks that operator new is avoided. Only the manual macOS phys_footprint table covers this.
    • zip_entry_buffer has no PyTorch-zip fixture (mutation M3 survives).
    • Out of scope, possible residue: model_manager.cpp:974 (load_tensor_parts) and load_float_tensor's loaded_data (model_loader.cpp:1486) still allocate tensor-sized buffers on the heap.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority:P2Important improvement or regression; schedule next

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions