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

Alternative I/O backend using io_uring on Linux #536

Open
JohannesLichtenberger opened this issue Oct 12, 2022 · 13 comments
Open

Alternative I/O backend using io_uring on Linux #536

JohannesLichtenberger opened this issue Oct 12, 2022 · 13 comments

Comments

@JohannesLichtenberger
Copy link
Member

in a package named org.sirix.io.iouring for instance and implement a Reader, Writer and Storage analogous to the other packages in org.sirix.io.

@JohannesLichtenberger
Copy link
Member Author

Maybe using https://github.com/ikorennoy/jasyncfio until Java's standard I/O supports io_uring the additional backend might be really helpful :-)

@sourabhkashyap95
Copy link

Hey @JohannesLichtenberger, planning to work on this issue.
Do we have any other lib implemented on io_uring? Also, like to make small changes related to a typo, but I think I don't have access to push changes.

@JohannesLichtenberger
Copy link
Member Author

I have recently started an issue over here how to proceed as it's not entirely clear to me: ikorennoy/jasyncfio#66

First of all I think we should switch to Java 19 and use virtual threads.

@JohannesLichtenberger
Copy link
Member Author

@sourabhkashyap95 I've added a blocking version which has to be adapted (and even the blocking version has at least one bug and is currently not working): https://github.com/sirixdb/sirix/tree/master/bundles/sirix-core/src/main/java/org/sirix/io/iouring

In order to debug the tests you can simply change the STORAGE_TYPE in ResourceConfiguration to StorageType.IO_URING

@sourabhkashyap95
Copy link

sourabhkashyap95 commented Oct 23, 2022

@JohannesLichtenberger , will go through the thread once and will check with you in case of any doubts.

@JohannesLichtenberger
Copy link
Member Author

@sourabhkashyap95 maybe you can debug reading/writing of page fragments (the variable length of a page -- for instance the UberPage currently is 27, but when read it's a bigger integer). I thought about byte order issues, as currently it's written in big endian, but read in little median byte order on my machine. But even if we're not using the native byte order for the ByteBuffers the bug persists.

@sourabhkashyap95
Copy link

@JohannesLichtenberger Currently I am trying to build the project but its failing, I think with this message /usr/local/bin/docker-compose: line 1: Not: command not found
It seems like docker-compose issue, currently, I am on Apple M1 pro chip, osx-x86_64 architecture.

@JohannesLichtenberger
Copy link
Member Author

You don't need Docker Compose. You can fork the repo, clone and open it in your IDE as a gradle project. Then you might make the aforementioned change and set breakpoints in the IOUringReader and IOUringWriter for instance when writing and reading the UberPage.

@JohannesLichtenberger
Copy link
Member Author

@sourabhkashyap95 hope it helps

@sourabhkashyap95
Copy link

@JohannesLichtenberger trying to run the tests changing the storage type but getting can't load native library as i have apple M1 machine.

@JohannesLichtenberger
Copy link
Member Author

Oh, I guess you'd need a recent Linux derivate. I've filed an issue with the library because of offset based writes: ikorennoy/jasyncfio#68 I think there's a bug in the library

@JohannesLichtenberger
Copy link
Member Author

JohannesLichtenberger commented Dec 2, 2022

On my new laptop with a PCIe 4.0 SSD sadly the io_uring layer for some reason is also consistently slower than the epoll based FileChannel implementation. I'd thought that even if it's not the most ideal way with more or less mostly synchronous I/O it should be faster in theory.

@JohannesLichtenberger
Copy link
Member Author

We should check if we can tune our current implementation, but in all my latency checks it was slower. I think in part it might be caused by the library and/or false parameters used. The event loop in the implementation seems to have some overhead.

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

No branches or pull requests

2 participants