Originally posted by oiaohm
View Post
Small file reads are in fact used a lot even in a sysvinit. You think PIDfile checking to prevent starting a service twice. There are quite a few small file usage presure points once you go looking for them. These are all hidden in utility programs that are used over and over again. Systemd with more complex cgroup process management is reading more small files. The effects of ulimit changes having to be shared also gets bigger. Think systemd is going to be used by KDE and Gnome around every started application.
The reality here is a straight up vectored syscall will not deal with the ulimit issue caused by open and close because you have it performing a normal syscall. A vectored syscall to properly handle error events is going to require setup so you cannot be sure u_ioring will be any worse than doing a vectored syscall due to how heavy doing proper error handing is going to be.
The reality here is a straight up vectored syscall will not deal with the ulimit issue caused by open and close because you have it performing a normal syscall. A vectored syscall to properly handle error events is going to require setup so you cannot be sure u_ioring will be any worse than doing a vectored syscall due to how heavy doing proper error handing is going to be.
Also error handling or a vectored syscall for the normal success case is as simple as for one read or open: it it returned success all vectored calls succeeded. Even for the error case it is not much harder, and could be abstracted in a libc readfile shim.
Yes readfile vs a vector syscall doing (open,read,close) the readfile is going to be faster because the vectored is going to have allow for the possibility it does not contain a close so change ulimit on open or close or process what vectored syscall has been passed to attempt to work out if it does not have to do ulimit change.
Vectored syscall is more flex able but it that flexibility that comes back and kicks you where it hurts with the open read close problem. Dealing with that flexibility issues does come with its own overhead problem.
Really I would like to see a writefile as well.
Vectored syscall is more flex able but it that flexibility that comes back and kicks you where it hurts with the open read close problem. Dealing with that flexibility issues does come with its own overhead problem.
Really I would like to see a writefile as well.
Those asking for a readfile syscall in Linux have correctly looked at the problem. Yes just like indepe said if you wanted vectored syscalls having readfile syscall is not mutually exclusive. You have failed to notice the all advantages the readfile syscall gets its reduction in syscalls it also reduction in atomic locking on ulimit a valve due to not needing to increase and decrease the file open count. Yes this is another bit of error handling how to handle the problem of max open file count.
For a everything is a file operating system having a open read close and open write close as single syscalls has their place.
Comment