Linux Work Culminating On A "READFILE" Syscall For Reading Small Files Efficiently

[phoronix]

Phoronix: Linux Work Culminating On A "READFILE" Syscall For Reading Small Files Efficiently

Stemming from recent kernel discussions over a hypothetical new system call for reading small files more efficiently, Greg Kroah-Hartman has been working on the readfile() system call and it's looking like it is taking shape well enough to premiere soon in a new mainline kernel release...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-READFILE-System-Call

[jacob]

Why does it need a new syscall? Couldn't an ioctl call do it?

[JustinTurdeau]

Why does it need a new syscall?

Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?

Couldn't an ioctl call do it?

How would that even work...?

[jacob]

Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?

No aversion, but they shouldn't be introduced at whim. Ideally only really new concepts should have new syscalls, new operations on existing object types should be implemented using existing generic interfaces.

[d4ddi0]

If "small" is defined as under 4k, and it's handled in a backwards compatible way in libc (maybe make open() a noop, only actually "opening" if the file is large or opened for writing, and close() also potentially a noop), this could be an improvement for 90% of all file accesses.

[d4ddi0]

Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?



How would that even work...?

LoL. y'all been TROLLED! a single ioctl was replaced by open, read/write, close, with the advent of sysfs attrributes.

[JustinTurdeau]

Ideally only really new concepts should have new syscalls, new operations on existing object types should be implemented using existing generic interfaces.

That's nonsense. Adding syscalls for performance reasons is totally legitimate; especially for use cases as common as this one. readv(), writev(), io_submit(), etc. also exist mostly for performance reasons.

If CPU vendors followed this mentality, we'd only have 10 instructions and everything would run dog slow.

[jacob]

That's nonsense. Adding syscalls for performance reasons is totally legitimate; especially for use cases as common as this one.

If CPU vendors followed this mentality, we'd only have 10 instructions and everything would run dog slow.

You realise that there is no performance difference whatsoever between ioctl() and a separate syscall, don't you? On a second thought, no, you probably don't.

An the reason that we don't have dog-slow CPUs is precisely because they have advanced addressing modes and a CISC instruction set that allows generating compact and highly optimised code. RISC (one operation = one instruction) has proven useful for designing small, power efficient and cheap cores, but performance-wise it has comprehensively lost to CISC.

[xpue]

Perhaps also should consider making system calls to work with multiple files/whatever in one call, in batches.

[jacob]

Perhaps also should consider making system calls to work with multiple files/whatever in one call, in batch mode.

Here is one I always wanted: be able to pass through a file descriptor. Say you want all input on fd X to be directly forwarded to output fd Y (by the kernel itself, without jumping into and back from user space). The splice() functionality kinda sorta lets you do that but it's clunky and doesn't work in all scenarios.