-
-
Notifications
You must be signed in to change notification settings - Fork 172
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.
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
Size-aware memory types #1031
Size-aware memory types #1031
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the TryFrom
conversions, you have some of the cases covered, but not all. Specifically, if you think of it as a 3x3 table where you're converting a type on the left to the type on the top:
Page4K | Page2M | Page 1G | |
---|---|---|---|
Page4K | auto. | fallible. | fallible. |
Page2M | infallible | auto | fallible. |
Page1G | infallible | infallible | auto. |
Notes:
- "auto" means it's covered by Rust's built-in blanket implementation, where
From
is always implemented for converting a type to itself. - "fallible" means that the conversion may fail due to improper page
number
alignment, so you must implement that withTryFrom
. - "infallible" means that the conversion is guaranteed to succeed, so you can implement it with
From
instead ofTryFrom
.
Aside from that, my main comment is to use generics everywhere. You're using them in about half of the places they could be used, which is good, but you shouldn't need to implement methods for specific Page<Page2MiB>
/Page<Page1GiB>
types hardly at all, except for the aforementioned conversion methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few more comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few more comments with a couple tiny mistakes found.
For these cases, your tests ought to catch such mistakes. If you don't have test cases to cover these, please add them and then ensure they all pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much Noah! Looking forward to seeing this in #1016!
* All chunk-related types are now parameterized with a `P: PageSize` type parameter: * `Page` and `Frame`, which ensure that the underlying virtual or physical address is always properly aligned to the specified size. * `PageRange` and `FrameRange`, which ensure that the range of pages or frames are correctly aligned and only can be created in granular chunks of the given `PageSize`. * When iterating over a range of huge pages or frames, each step will be at the granularity of one huge page, which makes it easy to iterate of huge pages and huge frames in lockstep. * There are various implementations of the conversion traits `From` and `TryFrom` for normal and huge pages/frames and ranges. * The `PageSize` parameter can only be one of 3 marker structs: 1. `Page4K`: a normal 4KiB page (P1-level), which is the default. 2. `Page2M`: a P2-level huge page. 3. `Page1G`: a P3-level huge page. * This is only relevant to x86_64 at the moment, though we may add aarch64 huge page sizes in the future too. Co-authored-by: Kevin Boos <kevinaboos@gmail.com> b521678
…os#1031) * All chunk-related types are now parameterized with a `P: PageSize` type parameter: * `Page` and `Frame`, which ensure that the underlying virtual or physical address is always properly aligned to the specified size. * `PageRange` and `FrameRange`, which ensure that the range of pages or frames are correctly aligned and only can be created in granular chunks of the given `PageSize`. * When iterating over a range of huge pages or frames, each step will be at the granularity of one huge page, which makes it easy to iterate of huge pages and huge frames in lockstep. * There are various implementations of the conversion traits `From` and `TryFrom` for normal and huge pages/frames and ranges. * The `PageSize` parameter can only be one of 3 marker structs: 1. `Page4K`: a normal 4KiB page (P1-level), which is the default. 2. `Page2M`: a P2-level huge page. 3. `Page1G`: a P3-level huge page. * This is only relevant to x86_64 at the moment, though we may add aarch64 huge page sizes in the future too. Co-authored-by: Kevin Boos <kevinaboos@gmail.com> b521678
Draft PR for huge pages without changes to the mapper.