CFQ - “In case of asynchronous requests, all the requests from all the processes are batched together according to their process's I/O priority”
Clash Royale CLAN TAG#URR8PPP
I think the following statements about CFQ contradict each other:
- "In case of asynchronous requests, all the requests from all the processes are batched together according to their process's I/O priority."
The only requests that the IO scheduler considers to be asynchronous are regular "buffered" writes.- "
ionicedoes nothing to de-prioritize asynchronous write IO."
Which statements are incorrect? Or if all of them are correct, why do they not contradict each other?
linux-kernel io
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
add a comment |
I think the following statements about CFQ contradict each other:
- "In case of asynchronous requests, all the requests from all the processes are batched together according to their process's I/O priority."
The only requests that the IO scheduler considers to be asynchronous are regular "buffered" writes.- "
ionicedoes nothing to de-prioritize asynchronous write IO."
Which statements are incorrect? Or if all of them are correct, why do they not contradict each other?
linux-kernel io
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
add a comment |
I think the following statements about CFQ contradict each other:
- "In case of asynchronous requests, all the requests from all the processes are batched together according to their process's I/O priority."
The only requests that the IO scheduler considers to be asynchronous are regular "buffered" writes.- "
ionicedoes nothing to de-prioritize asynchronous write IO."
Which statements are incorrect? Or if all of them are correct, why do they not contradict each other?
linux-kernel io
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
I think the following statements about CFQ contradict each other:
- "In case of asynchronous requests, all the requests from all the processes are batched together according to their process's I/O priority."
The only requests that the IO scheduler considers to be asynchronous are regular "buffered" writes.- "
ionicedoes nothing to de-prioritize asynchronous write IO."
Which statements are incorrect? Or if all of them are correct, why do they not contradict each other?
linux-kernel io
linux-kernel io
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
edited Feb 24 at 14:56
sourcejedi
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
asked Feb 13 at 13:48
sourcejedisourcejedi
24.8k441107
24.8k441107
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I believe statements 2 and 3 are incorrect.
It is possible for a user process to generate asynchronous write IOs using sync_file_range(). Since these IOs are submitted directly by the calling process, they could be affected by the process' IO priority.
sync_file_range() is designed to allow triggering async writeback. The current implementation (Linux v4.20) avoids setting REQ_SYNC, by using the writeback mode WB_SYNC_NONE. This is true even when your program waits for the writeback by including the flag SYNC_FILE_RANGE_WAIT_AFTER. (However, kernels between v2.6.29 and v4.4 incorrectly used WB_SYNC_ALL and hence REQ_SYNC for all writeback triggered by sync_file_range()).
I guess the process IO priority might also get used if it had to perform "direct reclaim" during an async write() call. That was allegedly gotten rid of in 2011.
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500393%2fcfq-in-case-of-asynchronous-requests-all-the-requests-from-all-the-processes%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I believe statements 2 and 3 are incorrect.
It is possible for a user process to generate asynchronous write IOs using sync_file_range(). Since these IOs are submitted directly by the calling process, they could be affected by the process' IO priority.
sync_file_range() is designed to allow triggering async writeback. The current implementation (Linux v4.20) avoids setting REQ_SYNC, by using the writeback mode WB_SYNC_NONE. This is true even when your program waits for the writeback by including the flag SYNC_FILE_RANGE_WAIT_AFTER. (However, kernels between v2.6.29 and v4.4 incorrectly used WB_SYNC_ALL and hence REQ_SYNC for all writeback triggered by sync_file_range()).
I guess the process IO priority might also get used if it had to perform "direct reclaim" during an async write() call. That was allegedly gotten rid of in 2011.
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
add a comment |
I believe statements 2 and 3 are incorrect.
It is possible for a user process to generate asynchronous write IOs using sync_file_range(). Since these IOs are submitted directly by the calling process, they could be affected by the process' IO priority.
sync_file_range() is designed to allow triggering async writeback. The current implementation (Linux v4.20) avoids setting REQ_SYNC, by using the writeback mode WB_SYNC_NONE. This is true even when your program waits for the writeback by including the flag SYNC_FILE_RANGE_WAIT_AFTER. (However, kernels between v2.6.29 and v4.4 incorrectly used WB_SYNC_ALL and hence REQ_SYNC for all writeback triggered by sync_file_range()).
I guess the process IO priority might also get used if it had to perform "direct reclaim" during an async write() call. That was allegedly gotten rid of in 2011.
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
add a comment |
I believe statements 2 and 3 are incorrect.
It is possible for a user process to generate asynchronous write IOs using sync_file_range(). Since these IOs are submitted directly by the calling process, they could be affected by the process' IO priority.
sync_file_range() is designed to allow triggering async writeback. The current implementation (Linux v4.20) avoids setting REQ_SYNC, by using the writeback mode WB_SYNC_NONE. This is true even when your program waits for the writeback by including the flag SYNC_FILE_RANGE_WAIT_AFTER. (However, kernels between v2.6.29 and v4.4 incorrectly used WB_SYNC_ALL and hence REQ_SYNC for all writeback triggered by sync_file_range()).
I guess the process IO priority might also get used if it had to perform "direct reclaim" during an async write() call. That was allegedly gotten rid of in 2011.
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
I believe statements 2 and 3 are incorrect.
It is possible for a user process to generate asynchronous write IOs using sync_file_range(). Since these IOs are submitted directly by the calling process, they could be affected by the process' IO priority.
sync_file_range() is designed to allow triggering async writeback. The current implementation (Linux v4.20) avoids setting REQ_SYNC, by using the writeback mode WB_SYNC_NONE. This is true even when your program waits for the writeback by including the flag SYNC_FILE_RANGE_WAIT_AFTER. (However, kernels between v2.6.29 and v4.4 incorrectly used WB_SYNC_ALL and hence REQ_SYNC for all writeback triggered by sync_file_range()).
I guess the process IO priority might also get used if it had to perform "direct reclaim" during an async write() call. That was allegedly gotten rid of in 2011.
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
answered Feb 24 at 15:07
sourcejedisourcejedi
24.8k441107
24.8k441107
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500393%2fcfq-in-case-of-asynchronous-requests-all-the-requests-from-all-the-processes%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown