feat(gds): enable parallel I/O thread pool for all cuFile filesystems#2802
feat(gds): enable parallel I/O thread pool for all cuFile filesystems#2802deng451e merged 2 commits intoLMCache:devfrom
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the performance of I/O operations by extending the use of a parallel I/O thread pool to all filesystems that utilize Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request enables the parallel I/O thread pool for all cuFile-enabled filesystems, not just WekaFS. This is achieved by tying the use_thread_pool flag to use_cufile. The thread name prefix is also made more generic. The changes are logical and correct. However, enabling this feature more broadly reveals a potential issue in the thread pool implementation (_batched_get_blocking_by_thread_pool_impl) where the memory format is not correctly handled during allocation. I've added a comment with details on this.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7b7336239a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
DongDongJu
left a comment
There was a problem hiding this comment.
LGTM. please revise two things.
DongDongJu
left a comment
There was a problem hiding this comment.
Thanks for the work. LGTM
Head branch was pushed to by a user without write access
Previously the thread pool for batched_get_blocking was only created on WekaFS, so cuFile on ext4, xfs, or other filesystems fell back to serial reads. Move `use_thread_pool` out of the WekaFS branch so it is set whenever cuFile is active, regardless of filesystem type. Also rename the thread-name prefix from "weka-gds-io" to "gds-io" to reflect the broader scope. Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com>
The thread pool implementation of batched_get_blocking was not passing the fmt parameter to allocate(), causing all allocations to use the default memory format regardless of what was stored in the cache. Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com>
…LMCache#2802) * feat(gds): enable parallel I/O thread pool for all cuFile filesystems Previously the thread pool for batched_get_blocking was only created on WekaFS, so cuFile on ext4, xfs, or other filesystems fell back to serial reads. Move `use_thread_pool` out of the WekaFS branch so it is set whenever cuFile is active, regardless of filesystem type. Also rename the thread-name prefix from "weka-gds-io" to "gds-io" to reflect the broader scope. Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com> * fix(gds): pass memory format in batched_get_blocking thread pool path The thread pool implementation of batched_get_blocking was not passing the fmt parameter to allocate(), causing all allocations to use the default memory format regardless of what was stored in the cache. Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com> --------- Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com>
…LMCache#2802) * feat(gds): enable parallel I/O thread pool for all cuFile filesystems Previously the thread pool for batched_get_blocking was only created on WekaFS, so cuFile on ext4, xfs, or other filesystems fell back to serial reads. Move `use_thread_pool` out of the WekaFS branch so it is set whenever cuFile is active, regardless of filesystem type. Also rename the thread-name prefix from "weka-gds-io" to "gds-io" to reflect the broader scope. Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com> * fix(gds): pass memory format in batched_get_blocking thread pool path The thread pool implementation of batched_get_blocking was not passing the fmt parameter to allocate(), causing all allocations to use the default memory format regardless of what was stored in the cache. Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com> --------- Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com>
Previously the thread pool for batched_get_blocking was only created on WekaFS, so cuFile on ext4, xfs, or other filesystems fell back to serial reads.
Move
use_thread_poolout of the WekaFS branch so it is set whenever cuFile is active, regardless of filesystem type. Also rename the thread-name prefix from "weka-gds-io" to "gds-io" to reflect the broader scope.What this PR does / why we need it:
Special notes for your reviewers:
If applicable: