Skip to content

Increase the OOM allocation size to max precise value #4489

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 28, 2025
Merged

Increase the OOM allocation size to max precise value #4489

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 1 addition & 6 deletions src/webgpu/api/operation/buffers/map_oom.spec.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,12 +10,7 @@ import { kMaxSafeMultipleOf8 } from '../../../util/math.js';
const oomAndSizeParams = kUnitCaseParamsBuilder
.combine('oom', [false, true])
.expand('size', ({ oom }) => {
return oom
? [
kMaxSafeMultipleOf8,
0x20_0000_0000, // 128 GB
Copy link
Collaborator

@kainino0x kainino0x Oct 28, 2025

Choose a reason for hiding this comment

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

Just FYI, I think the reason to test both kMaxSafeMultipleOf8 and 128 GB was that we expected kMaxSafeMultipleOf8 to hit some hardcoded limit and 128 GB to hit an actual OOM. Unfortunately we did expect that to be possibly unreliable, so it was one of those test cases I call "aspirational".

Copy link
Contributor Author

@zoddicus zoddicus Oct 28, 2025

Choose a reason for hiding this comment

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

Do you think it would be useful to introduce a new version of the 'actual OOM' limit, maybe 4TB or some other value, with a note about it potentially needing to upped in the future, or is it likely we are already getting into the space where it will be hard to distinguish between a hardcoded limit and a true OOM?

Did a brief investigation on what current operation system RAM limits look like, and Windows 11 supports between 128GB and 6TB of RAM depending on the license/version. And I believe the current memory page scheme of the Linux kernel has a theoretical ceiling of 4 PB of RAM.

So we are kinda in a world already where I can build a workstation with more that the maximum amount of RAM for a 'common' OS. So I am not sure how much having a seperate test value would give us, and I really don't like the idea of trying to do some sort of OS inspection to figure out an appropriate value.

Copy link
Collaborator

@kainino0x kainino0x Oct 30, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

We should probably just leave it up to individual implementations to test this if they want to, since there's no way to know the hardcoded OOM threshold. Also that way the test could have some backdoor to see whether an OOM is real (came from the underlying API) or hardcoded.

]
: [16];
return oom ? [kMaxSafeMultipleOf8] : [16];
});

export const g = makeTestGroup(AllFeaturesMaxLimitsGPUTest);
Expand Down