New readfile() System Call Under Review For Reading Small~Medium Files Faster

[markg85]

markg85 whoever said I was using a Pi? It was an i.MX 5 SoM. And yes, fast switching was kind of stupid, but our client wanted it so what was I to do? Also, on a single core 500 MHz Cortex-A7 I'll take all the savings I can get.

Oops, i messed up there. I read @milkylainen post first (which mentions the raspberry pi and was a reply to yours) and blindly assumed that you were using a raspberry pi. I did read your post but just assumed the wrong thing. Sorry for that.

I stand by my suggestion that you should probably need to go for an RTOS system. Also, who knows better? You, the developer, or your client? I'm going to assume (again) that you know better and should convince your client of the better approach.

[jaskij]

markg85 whoever said I was using a Pi? It was an i.MX 5 SoM. And yes, fast switching was kind of stupid, but our client wanted it so what was I to do? Also, on a single core 500 MHz Cortex-A7 I'll take all the savings I can get.

[markg85]

Guest I've run precisely into this sysfs bottleneck when doing fast switching of GPIOs in an industrial PC. I ended up keeping those fds open and doing seek()/write() over open()/write()/close() - it cut down my CPU utilization by 90%.

You are abusing the platform. Industrial + raspberry pi does not mix well.
You should be using a RTOS platform. Even an ESP8266 would be better suited in your case.

[markg85]

Can anyone tell me the maximum filesize for this syscall?
Yes, i did read the code, and the new manpage. Nothing seems to indicate what qualifies as "small". The post also mentions "small and medium sizes".

It even has testcases:

+ test_filesize(0x10);
+ test_filesize(0x100);
+ test_filesize(0x1000);
+ test_filesize(0x10000);
+ test_filesize(0x100000);
+ test_filesize(0x1000000);

Where that largest testcase is 16 MiB.

I'm asking because i want to know if this syscall can be used to, for example, load icons and config files. Now config files are likely sub megabyte ones. But icons can be multiple megabytes (think about ico files that contain multiple images). But besides that, think about reading thumbnails for display in, say, dolphin or gwenview etc...

Now i'm not betting on this to be "substantially faster" then 3 syscalls (open/read/close) as the syscalls themselves are probably just a tiny percentage of actually handling the file data to do something with it (say jpeg/png/svg/webp decoder). But still, if you expand this over large folders it might become a notable difference.

Lastly, and this one is specifically for phoronix. Greg is, in the next version of this patch, going to post benchmarks too: https://lore.kernel.org/lkml/[email protected]/

[milkylainen]

Guest I've run precisely into this sysfs bottleneck when doing fast switching of GPIOs in an industrial PC. I ended up keeping those fds open and doing seek()/write() over open()/write()/close() - it cut down my CPU utilization by 90%.

Sorry. But that's just stupid. Doing high volume GPIO-switching from userspace using sysfs...
I see these tendencies all over the place. "I have installed a Raspberry Pi. I know embedded!".
Sysfs was never meant as a high speed/volume interface and this does not change that.
It just reduces the amount of syscalls from userspace.
The kernel still has to do vfs-crap and open/seek/read/close for every state.
And that's for something that should be a byte memory access read away in a CPU GPIO bank register.

[jaskij]

Guest I've run precisely into this sysfs bottleneck when doing fast switching of GPIOs in an industrial PC. I ended up keeping those fds open and doing seek()/write() over open()/write()/close() - it cut down my CPU utilization by 90%.

[intelfx]

Is there a real-world scenario in which open/read/close of sysfs and procfs files is a bottleneck?

Not sure — but I didn't make this up, it's just the rationale from the lkml thread:

<...>
This is especially helpful for tools that poke around in procfs or sysfs, making a little bit of a less system load than before, especially as syscall overheads go up over time due to various CPU bugs being addressed.
<...>

[ssokolow]

For everybody, who is also wondering why you'd need to pass a file descriptor : it is the file descriptor of the directory this file lives in. You've to 'open' the directory first. Source : patches

I can think of two reasons to do it that way off the top of my head:

1. Linux has no path length limit. Some legacy POSIX APIs are limited to 4096 characters, but filesystems like ext4 have no path length limit and you can work around the API limits using relative paths.
2. It's getting more popular to compile code to ABIs where all paths must be relative to file descriptors passed in by the sandbox host. (i.e. The binary does not have access to any syscalls that accept absolute paths)

[intelfx]

At first, I thought that the proposed system call is capable of reading multiple small files using a single system call - which would help increase HDD/SSD queue utilization and increase IOPS (I/O operations per second) - but that isn't the case and the proposed system call can read just a single file. Without the ability to read multiple small files using a single system call, it is impossible to increase IOPS (unless using multiple threads).

https://en.wikipedia.org/wiki/Native_Command_Queuing

There are no queues and iops in sysfs and procfs This syscall is not about better hardware utilization, it's about doing fewer syscalls.

If you are at the point of being bothered by queue utilization, then you should already be using async I/O (cf. io_uring).

[oleid]

At first, I thought that the proposed system call is capable of reading multiple small files using a single system call - which would help increase HDD/SSD queue utilization and increase IOPS (I/O operations per second) - but that isn't the case and the proposed system call can read just a single file. Without the ability to read multiple small files using a single system call, it is impossible to increase IOPS (unless using multiple threads).

https://en.wikipedia.org/wiki/Native_Command_Queuing

It is not too late, comment those patches on the mailing list