io - How performance of reads/writes to regular file varies when linux kernel memory load becomes high? -

it seems writes/reads regular files can't not made non-blocking. found following references support:

from linux programming interface: linux , unix system programming handbook:

"--- nonblocking mode can used devices (e.g., terminals , pseudoterminals), pipes, fifos, , sockets. (because file descriptors pipes , sockets not obtained using open(), must enable flag using fcntl() f_setfl operation described in section 5.3.) o_nonblock ignored regular files, because kernel buffer cache ensures i/o on regular files not block, described in section 13.1. however, o_nonblock have effect regular files when mandatory file locking employed (section 55.4). ---"

from advanced programming in unix environment 2nd ed:

"--- said system calls related disk i/o not considered slow, though read or write of disk file can block caller temporarily. ---"

from http://www.remlab.net/op/nonblock.shtml:

"--- regular files readable , writeable. stated in relevant posix specifications. cannot stress enough. putting regular file in non-blocking has absolutely no effects other changing 1 bit in file flags. reading regular file might take long time. instance, if located on busy disk, i/o scheduler might take time user notice application frozen. nevertheless, non-blocking mode not work. not work. checking file readability or writeability succeeds immediately. if system needs time perform i/o operation, put task in non-interruptible sleep read or write system call. ---"

when memory adequately available, reads/writes performed through kernel buffering.

my question is: there scenario kernel out of memory buffering not usable immediately? if yes, kernel do? returns error or amazing trick?

thanks guys!

my take on o_nonblock , on quoted text:

• o_nonblock has absolutely no effect if syscall triggers actual disk i/o blocks or not waiting i/o complete. o_nonblcok affects filesystem level operations such accesses pseudo-files (as first quote mentions) , locked files. o_nonblock not affect operations @ block device level.

• lack of memory has nothing o_nonblock.

• o_nonblock dictates if accesses locked files block or not. example, flock() / lockf() can used lock file. if o_nonblock used, read()/write() return egain instead of blocking , waiting file lock released. please keep in mind synchronization differences implemented @ level of filesystem level , have nothing whether read()/write() syscall triggers true disk i/o.

• the fragment because kernel buffer cache ensures i/o on regular files not block first quote misleading , go far considering wrong. true buffering lowers chance file read/write syscall result in disk i/o , block, however, buffering alone can never avoid i/os. if file not cached, kernel needs perform actual io when read() file. if write() file , page cache full dirty pages, kernel has make room first flushing data storage device. i feel if mentally skip fragment text becomes more clear.

• the second quote seems generic (what mean slow?) , provides no explanation of why i/o-related calls not considered slow. suspect there more background information in text around qualifies bit more author intended say.

• lack of memory in kernel can come in 2 forms: (a) lack of free pages in buffer cache , (b) not enough memory allocate new data structures servicing new syscalls. (a) kernel recycles pages in buffer cache, possibly writing dirty pages first disk. common scenario. (b) kernel needs free memory either paging program data swap partition or (if fails) killing existing process (the oom function invoked pretty kills process biggest memory consumption). uncommon mode of operation system continue running after user process killed.