4 ms·
You've essentially just waved your hands. Conditional complication is not an issue at all; anyone working on a large portable program is going to have large sw
by spudlyo 13y ago
You've essentially just waved your hands. Conditional complication is not an issue at all; anyone working on a large portable program is going to have large swaths of conditionally compiled code. Phrases like "resource management responsibility" and "substantial indirect overhead" are pretty vague, and aren't really helping me understand why O_DIRECT can't be used.
It turns off a lot of OS features most developers take for granted.
Yeah, like OS buffering. What else?
- jandrewrogers 13y agoI use O_DIRECT almost exclusively in the software I write; I am familiar with the overhead. You can use O_DIRECT very easily without a lot of overhead if you wish but the performance will be much worse than not using it unless you competently reimplement many other parts of the OS functionality at the same time. To use O_DIRECT effectively in Linux, at a minimum you need to write a buffer cache that is both fast and adaptive to workloads with proper cache replacement schedulers (no LRU crap), you need to write a complete I/O scheduler replacement (e.g. using io_submit and related interfaces) which is not portable at all, and you need to stop using almost all file system APIs (it interferes with the I/O scheduling bypass). O_DIRECT is easy to use for very narrow cases. Taking advantage of it for anything slightly complicated in terms of file I/O usage and you bite off a lot more low-level implementation or the performance will actually be worse.