| Age | Commit message (Collapse) | Author |
|---|
|
In general, the new NIF-based file routines are faster than the old
efile driver.
However, on some computers, building the entire OTP system is somewhat
slower. It turns out that it is because 'erlc' cheated by turning off
the IO thread pool (using '+A0') to avoid context switches between
scheduler threads and threads in the IO thread pool. The new file
routines perform IO on dirty IO threads, and there is (by intent) no
way to force the operations to occur on scheduler threads to avoid
the context switches
What we can do to is to use a small (4Kb) read-ahead buffer for files
opened for reading (only) in list mode (which is how the compiler
opens its input files). The buffering reduces the number of context
switches between scheduler threads and dirty IO threads. On my
computer that seems to slightly speed up building of the entire OTP
system.
The buffer should do no harm. The only potential for harm I can
think of is random access to a file opened in read mode, where
the read-ahead buffer could slightly decrease performance. That
does not seems to be a likely use case in practice, though.
|
|
This improves the latency of file operations as dirty schedulers
are a bit more eager to run jobs than async threads, and use a
single global queue rather than per-thread queues, eliminating the
risk of a job stalling behind a long-running job on the same thread
while other async threads sit idle.
There's no such thing as a free lunch though; the lowered latency
comes at the cost of increased busy-waiting which may have an
adverse effect on some applications. This behavior can be tweaked
with the +sbwt flag, but unfortunately it affects all types of
schedulers and not just dirty ones. We plan to add type-specific
flags at a later stage.
sendfile has been moved to inet_drv to lessen the effect of a nasty
race; the cooperation between inet_drv and efile has never been
airtight and the socket dying at the wrong time (Regardless of
reason) could result in fd aliasing. Moving it to the inet driver
makes it impossible to trigger this by closing the socket in the
middle of a sendfile operation, while still allowing it to be
aborted -- something that can't be done if it stays in the file
driver.
The race still occurs if the controlling process dies in the short
window between dispatching the sendfile operation and the dup(2)
call in the driver, but it's much less likely to happen now.
A proper fix is in the works.
--
Notable functional differences:
* The use_threads option for file:sendfile/5 no longer has any
effect.
* The file-specific DTrace probes have been removed. The same
effect can be achieved with normal tracing together with the
nif__entry/nif__return probes to track scheduling.
--
OTP-14256
|
|
* soranoba/fix-file-position/PR-646:
Unify internal error handling
Fix file:pread and :pwrite to use character encoding
Clean up code for file:position/2
Fix file:position (not raw mode)
OTP-13155
|
|
|
|
|
|
|
|
|
|
When it called the "file:position", it subtract the size that was
read into the buffer, and returns the value.
However, it has been discarded buffer and correct position is lost,
if "file:postion" returns error.
|
|
When a file was opened with some unicode encoding, file:read_line/1
could return unicode codepoints > 255 in list mode and wrong error
message in bin mode.
Chose to break out 'get_line' functionality from get_chars/5 since
'get_until' handling is different (comes from io module which should
return unicode lists) and seems to have its own (doc?) problems.
|
|
|
|
|
|
This operation allows pre-allocation of space for files.
It succeeds only on systems that support such operation.
The POSIX standard defines the optional system call
posix_fallocate() to implement this feature. However,
some systems implement more specific functions to
accomplish the same operation.
On Linux, if the more specific function fallocate() is
implemented, it is used instead of posix_fallocate(),
falling back to posix_fallocate() if the fallocate()
call failed (it's only supported for the ext4, ocfs2,
xfs and btrfs file systems at the moment).
On Mac OS X it uses the specific fcntl() operation
F_PREALLOCATE, falling back to posix_fallocate() if
it's available (at the moment Mac OS X doesn't provide
posix_fallocate()).
On any other UNIX system, it uses posix_fallocate() if it's
available. Any other system not providing this system call
or any function to pre-allocate space for files, this operation
always fails with the ENOTSUP POSIX error.
|
|
Expect modifications, additions and corrections.
There is a kludge in file_io_server and
erl_scan:continuation_location() that's not so pleasing.
|
|
|
|
|
|
|
|
User tags in a dynamic trace enabled VM are spread throughout the system
in the same way as seq_trace tokens. This is used by the file module
and various other modules to get hold of the tag from the user process
without changing the protocol.
|
|
Add probes to (mostly) the efile_drv.c driver and other
file I/O-related source files.
|
|
|
|
Useful for informing the Operating System about the access pattern
for a file's data, so that it can adapt the caching strategy to
maximize disk IO performance.
|
|
file:datasync/1 invokes the POSIX system call "int fdatasync(int fd)".
This system call is similar to "fsync" but, unlike fsync, it does not
update the metadata associated with the file (like the access time for
example). It's used by many DBMSs (MySQL and SQLite of example) to
increase disk IO performance, as it avoids disk seeks and disk write
operations compared to fsync.
More details on it at:
http://linux.die.net/man/2/fdatasync
An example, from the MySQL source:
http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.1-telco-6.1/annotate/head%3A/mysys/my_sync.c#L61
This new function just calls fsync on systems not implementing fdatasync.
|
|
* ks/kernel:
kernel: Clean up as suggested by tidier
OTP-8606 ks/kernel
|
|
|
|
|
