[DiscordArchive] The kernel can handle this stuff way better and already has to do so anyway since multiple processes
[DiscordArchive] The kernel can handle this stuff way better and already has to do so anyway since multiple processes
Original source
The kernel can handle this stuff way better and already has to do so anyway since multiple processes may access the same file?
rektbyfaith
06-18-2018, 02:33 PM #1Archived author: schlumpf • Posted: 2018-06-18T14:33:46.116000+00:00
Original source
The kernel can handle this stuff way better and already has to do so anyway since multiple processes may access the same file?
Original source
Also, reading already is a syscall so you're in kernel space anyway and it isn't additional overhead.
rektbyfaith
06-18-2018, 02:34 PM #2Archived author: schlumpf • Posted: 2018-06-18T14:34:09.171000+00:00
Original source
Also, reading already is a syscall so you're in kernel space anyway and it isn't additional overhead.
Original source
You can also map files into memory to have similar stuff
rektbyfaith
06-18-2018, 02:34 PM #3Archived author: Deleted User • Posted: 2018-06-18T14:34:11.393000+00:00
Original source
You can also map files into memory to have similar stuff
Original source
In fact, it likely is more efficient for the kernel to do it.
rektbyfaith
06-18-2018, 02:34 PM #4Archived author: schlumpf • Posted: 2018-06-18T14:34:18.071000+00:00
Original source
In fact, it likely is more efficient for the kernel to do it.
Original source
Not sure how Linux or traditional Unix works, but in Windows ALL I/O is async internally. Sync I/O is just passing the kernel an event to be set when the I/O is completed and then sleeping on it, in user mode
rektbyfaith
06-18-2018, 02:34 PM #5Archived author: Quantam • Posted: 2018-06-18T14:34:46.566000+00:00
Original source
Not sure how Linux or traditional Unix works, but in Windows ALL I/O is async internally. Sync I/O is just passing the kernel an event to be set when the I/O is completed and then sleeping on it, in user mode
Original source
Actually I'm not certain about the user mode part. Might be in kernel mode so it can update the file pointer before it returns.
rektbyfaith
06-18-2018, 02:36 PM #6Archived author: Quantam • Posted: 2018-06-18T14:36:25.689000+00:00
Original source
Actually I'm not certain about the user mode part. Might be in kernel mode so it can update the file pointer before it returns.
Original source
In either case allowing many requests to go the the HD simultaneously provides a speed boost because modern HD firmware performs rotational optimization of requests
rektbyfaith
06-18-2018, 02:37 PM #7Archived author: Quantam • Posted: 2018-06-18T14:37:58.568000+00:00
Original source
In either case allowing many requests to go the the HD simultaneously provides a speed boost because modern HD firmware performs rotational optimization of requests
Original source
Well, for a fact, Win I/O has sync and async version. Async version requires user to pass Overlapped structure, which afaik has mutex handler inside
rektbyfaith
06-18-2018, 02:38 PM #8Archived author: Deamon • Posted: 2018-06-18T14:38:44.506000+00:00
Original source
Well, for a fact, Win I/O has sync and async version. Async version requires user to pass Overlapped structure, which afaik has mutex handler inside
Original source
Even bigger gains are possible for SSDs that can perform transfers from multiple chips in parallel
rektbyfaith
06-18-2018, 02:39 PM #9Archived author: Quantam • Posted: 2018-06-18T14:39:09.977000+00:00
Original source
Even bigger gains are possible for SSDs that can perform transfers from multiple chips in parallel
Original source
For sync the overlapped is allocated on the stack and a thread event is used instead of an explicit one
rektbyfaith
06-18-2018, 02:39 PM #10Archived author: Quantam • Posted: 2018-06-18T14:39:57.237000+00:00
Original source
For sync the overlapped is allocated on the stack and a thread event is used instead of an explicit one
1 Guest(s)
1 Guest(s)