Skip to content
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

refactor(blob_io): use owned buffers #6660

Conversation

problame
Copy link
Contributor

@problame problame commented Feb 7, 2024

This PR refactors the blob_io code away from using slices towards taking owned buffers and return them after use.
Using owned buffers will eventually allow us to use io_uring for writes.

part of #6663

Depends on neondatabase/tokio-epoll-uring#43

The high level scheme is as follows:

  • call writing functions with the BoundedBuf
  • return the underlying BoundedBuf::Buf for potential reuse in the caller

NB: Invoking BoundedBuf::slice(..) will return a slice that includes the uninitialized portion of BoundedBuf.
I.e., the portion between bytes_init() and bytes_total().
It's a safe API that actually permits access to uninitialized memory.
Not great.

Another wrinkle is that it panics if the range has length 0.

However, I don't want to switch away from the BoundedBuf API, since it's what tokio-uring uses.
We can always weed this out later by replacing BoundedBuf with our own type.
Created an issue so we don't forget: neondatabase/tokio-epoll-uring#46

We can probably get rid of the entire trait, but, that's for another time.
…uilder-refactor' into problame/integrate-tokio-epoll-uring/write-path/simplify-write-at-api
Copy link

github-actions bot commented Feb 7, 2024

2430 tests run: 2319 passed, 0 failed, 111 skipped (full report)


Flaky tests (1)

Postgres 14

  • test_pg_regress[4]: debug

Code coverage (full report)

  • functions: 54.8% (11830 of 21576 functions)
  • lines: 82.1% (66104 of 80517 lines)

The comment gets automatically updated with the latest test results
4227e42 at 2024-02-12T13:59:49.623Z :recycle:

@problame problame changed the title refactor(blob_writer): transition write path to owned buffers refactor(blob_io): use owned buffers Feb 7, 2024
problame added a commit to neondatabase/tokio-epoll-uring that referenced this pull request Feb 8, 2024
@problame problame requested a review from VladLazar February 8, 2024 10:57
@problame problame marked this pull request as ready for review February 8, 2024 10:57
@problame problame requested a review from a team as a code owner February 8, 2024 10:57
Copy link
Contributor

@VladLazar VladLazar left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@koivunej koivunej left a comment

Choose a reason for hiding this comment

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

Seeing these parts for the first time, cannot spot any problems.

@problame problame merged commit 242dd83 into main Feb 12, 2024
49 checks passed
@problame problame deleted the problame/integrate-tokio-epoll-uring/write-path/refactor-blob-writer branch February 12, 2024 14:58
pageserver/src/tenant/blob_io.rs Show resolved Hide resolved
pageserver/src/tenant/blob_io.rs Show resolved Hide resolved
io_buf,
Err(Error::new(
ErrorKind::Other,
format!("blob too large ({} bytes)", len),
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
format!("blob too large ({} bytes)", len),
format!("blob too large ({len} bytes)"),

let mut len_buf = (len as u32).to_be_bytes();
len_buf[0] |= 0x80;
io_buf.extend_from_slice(&len_buf[..]);
self.write_all(io_buf).await
Copy link
Member

Choose a reason for hiding this comment

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

the write call can be moved out of the if as both branches have it.


let mut io_buf = self.io_buf.take().expect("we always put it back below");
io_buf.clear();
let (io_buf, hdr_res) = async {
Copy link
Member

Choose a reason for hiding this comment

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

it's not 100% clear to me why there is an async block here. It would be useful to have a comment that explains it also for other future readers. I suppose some ownership/borrow checker issue?

jcsp pushed a commit that referenced this pull request Feb 12, 2024
This PR refactors the `blob_io` code away from using slices towards
taking owned buffers and return them after use.
Using owned buffers will eventually allow us to use io_uring for writes.

part of #6663

Depends on neondatabase/tokio-epoll-uring#43

The high level scheme is as follows:
- call writing functions with the `BoundedBuf`
- return the underlying `BoundedBuf::Buf` for potential reuse in the
caller

NB: Invoking `BoundedBuf::slice(..)` will return a slice that _includes
the uninitialized portion of `BoundedBuf`_.
I.e., the portion between `bytes_init()` and `bytes_total()`.
It's a safe API that actually permits access to uninitialized memory.
Not great.

Another wrinkle is that it panics if the range has length 0.

However, I don't want to switch away from the `BoundedBuf` API, since
it's what tokio-uring uses.
We can always weed this out later by replacing `BoundedBuf` with our own
type.
Created an issue so we don't forget:
neondatabase/tokio-epoll-uring#46
problame added a commit that referenced this pull request Feb 13, 2024
…6664)

Building atop #6660 , this PR converts VirtualFile::write_all to
owned buffers.

Part of #6663
@problame
Copy link
Contributor Author

For the record, @arpad-m and I had a call where I explained the questions above.
The PR description contains sufficient information.

@arpad-m
Copy link
Member

arpad-m commented Feb 13, 2024

The call addressed my first two concerns, which turn out to be due to shortcomings in the API. The three last comments in the review still apply though. Would be great to have a followup PR for them, but not extremely neccessary as they are just nits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants