Skip to content

Fix #2049: Expose Buffer._size to Python#2068

Open
mdboom wants to merge 1 commit into
NVIDIA:mainfrom
mdboom:issue2049
Open

Fix #2049: Expose Buffer._size to Python#2068
mdboom wants to merge 1 commit into
NVIDIA:mainfrom
mdboom:issue2049

Conversation

@mdboom
Copy link
Copy Markdown
Contributor

@mdboom mdboom commented May 12, 2026

_grow_allocation_fast_path was not being tested in CI, and static type-checking discovered an attribute error lurking within it.

This new test is entirely agent-written and I don't personally understand this part of the system, so please give it extra scrutiny.

The bugfix itself is simple, but also could be removed when/if _virtual_memory_resource.py is Cythonized, since it could cimport Buffer and get access to _size that way.

@mdboom mdboom requested a review from Andy-Jost May 12, 2026 14:27
@github-actions github-actions Bot added the cuda.core Everything related to the cuda.core module label May 12, 2026
@github-actions
Copy link
Copy Markdown

cdef public:
# Python code in _memory/_virtual_memory_resource.py needs to update
# this value, though it is technically private.
size_t _size
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

@mdboom mdboom May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could make that property settable (it's currently readonly), but I assumed we didn't want to make settabilility part of the public API -- seems kinda dangerous. So I exposed _size as a _-prefixed member instead.

@leofang
Copy link
Copy Markdown
Member

leofang commented May 12, 2026

Do we know why this did not trip in the CI? #2049 (comment)

@mdboom
Copy link
Copy Markdown
Contributor Author

mdboom commented May 12, 2026

Do we know why this did not trip in the CI? #2049 (comment)

My agent's assessment:

vmm_mr.allocate(2 * 1024 * 1024) reserves only that 2 MB range; nothing guarantees the next VA page is unreserved. In practice the CUDA driver's cuMemAddressReserve with a fixedAddr hint typically returns CUDA_SUCCESS but with a different address (the hint is advisory). That trips the new_ptr != int(buf.handle) + aligned_prev_size branch, the reservation is freed, and execution falls through to _grow_allocation_slow_path.

The test author already noticed this — the comment at test_memory.py:955-956 literally says "Because of the slow path, the pointer may change … we can assert that a new pointer was assigned". So the test was written knowing only the slow path runs.

Copy link
Copy Markdown
Contributor

@Andy-Jost Andy-Jost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

I don't particularly like the VVM interface forcing Buffer to be mutable but that's not in scope for this PR.

@mdboom
Copy link
Copy Markdown
Contributor Author

mdboom commented May 12, 2026

I don't particularly like the VVM interface forcing Buffer to be mutable but that's not in scope for this PR.

Should we create a new issue to follow-up for that? I'm not as familiar with this code so I don't know what that would look like...

@mdboom mdboom added bug Something isn't working P0 High priority - Must do! labels May 12, 2026
@mdboom mdboom added this to the cuda.core next milestone May 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working cuda.core Everything related to the cuda.core module P0 High priority - Must do!

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants